You are picking a garbage collector for a latency-sensitive JVM service and are considering ZGC, the sub-millisecond colored-pointer collector. What do you gain, what do you pay for it, and what failure mode should you size capacity around?

## Frame the decision honestly A collector choice is a resource trade, not a ranking. ZGC buys one property — **pause time independent of heap size and live-set size** — and charges for it in throughput, CPU, and memory. The question to answer is whether that property is on your critical path. It usually is when: your service has a strict tail-latency SLO (p99.9 in single-digit or low tens of milliseconds); your live set is large enough that a stop-the-world compaction would be measured in hundreds of milliseconds or seconds; or your heap is large enough (hundreds of GB and up) that other collectors' pauses become unmanageable. It usually is not when the workload is batch or throughput-oriented, where a throughput-first collector gets more work done per core and nobody is watching a latency histogram. ## What you gain, precisely - **Bounded pauses.** Sub-millisecond stop-the-world phases whose cost tracks the root set, not the heap. A 500 GB heap pauses like a 5 GB one. - **Concurrent compaction.** Defragmentation happens every cycle without a pause, so you do not accumulate fragmentation debt that eventually forces an emergency full collection. - **Headroom to grow the heap.** Because pauses do not lengthen, adding memory is a viable answer to allocation pressure, which is not true of collectors whose pauses scale with the live set. - **Very little tuning surface.** Practically: choose the collector, set a heap size, provide CPU. There is no generation-sizing exercise. ## What you pay, precisely **Throughput.** Every reference load from the heap carries a barrier check. Measured cost is workload-dependent: often a few percent, more for code that chases pointers through large data structures in tight loops, near zero for services dominated by I/O or primitive computation. Generational ZGC also adds a store barrier. If your service is CPU-bound on object graph traversal, benchmark before committing. **CPU.** Concurrent collection means GC threads run *alongside* your threads. On a box already at 90 % CPU, the collector cannot get the cycles it needs and the effect surfaces as latency, then as stalls. ZGC deployments need genuine CPU headroom; treat GC threads as a first-class consumer in capacity planning, not as free background work. **Memory.** Two distinct costs. First, **headroom**: the application allocates during the whole cycle and relocation needs empty pages to copy survivors into, so a heap sized to just fit the live set will stall. Second, **no compressed oops**: every reference is 8 bytes, where G1 below roughly 32 GB uses 4. For reference-dense heaps that is a real footprint increase and some cache-density loss. Generational ZGC substantially reduced the headroom requirement, but it did not remove it. ## The failure mode to design around This is the part that separates a considered answer from a memorized one. Collectors that pause degrade *gracefully-looking* — pauses simply get longer. ZGC does not: it holds pauses at sub-millisecond and instead, when it cannot free memory fast enough, makes allocating threads **stall** until memory becomes available. A stall can be orders of magnitude longer than any pause. So the operational discipline is: 1. **Alert on allocation stalls**, not only on pause times. A dashboard showing max pause = 0.08 ms tells you nothing about whether threads are waiting for memory. 2. **Provision headroom deliberately.** Establish the steady-state live set from GC logs and size the heap well above it, with enough margin to absorb traffic spikes and any known bursty allocation (large request payloads, batch jobs colocated with request handling). 3. **Provision CPU.** If GC threads cannot run, nothing else in the design saves you. 4. **Use generational ZGC** (the default on current JDKs) — it needs materially less CPU and headroom for the same allocation rate. 5. **Attack allocation rate itself** when stalls appear. Reducing garbage produced per request is often cheaper than adding memory, and it is the only fix that scales. ## Do not oversell the latency claim A sub-millisecond GC pause is one component of tail latency. The remainder still contains: other safepoint operations unrelated to GC; JIT compilation and deoptimization; OS-level effects such as page faults, swap, CPU steal on shared hosts, and NUMA misplacement; lock contention and queueing in your own code. Teams that migrate to ZGC and still see 50 ms tails are usually looking at one of those. State the boundary of the claim: ZGC removes GC pauses from your tail budget; it does not make the rest of the system real-time. ## How to decide in practice Measure, do not assume. Run the workload with the current collector and with ZGC, at realistic allocation rates and heap sizes, and compare three numbers: throughput (requests/sec at fixed CPU), the latency tail (p99.9, not the mean), and stability under a spike. Then price the difference — extra cores and extra RAM against the SLO the pause reduction protects. If nobody can name the SLO the change protects, the answer is that you do not need it yet.