Stop-the-World GC Pauses and How to Reduce Them

A safepoint is a point in a thread's execution where its internal state (register contents, stack layout, object references) is fully known and safe to inspect — the JVM can only pause a thread for GC (or run other VM operations, like deoptimization or a thread dump) once every running thread has reached one. Time-to-safepoint is how long the JVM waits for the slowest thread to get there; a thread stuck in a tight loop with no safepoint poll (rare, but possible in JIT-compiled code with no back-edges) or blocked in a long native call can stall the entire STW pause, not just its own work — so a GC pause you measure isn't just "the GC's actual work," it also includes however long the slowest thread took to reach a safepoint.

Even a "concurrent" collector (G1, ZGC, Shenandoah) isn't fully concurrent — each still has short mandatory STW phases. G1's young/mixed collections are themselves STW (it's concurrent only for the old-gen marking phase); ZGC and Shenandoah do almost everything concurrently but still briefly pause to mark GC roots (thread stacks, static fields) at the very start of a cycle, because roots can change while a thread runs and the set has to be captured atomically. The difference from a fully-STW collector like Parallel GC isn't "zero pauses" — it's that the unavoidable pause is O(number of roots), not O(live heap size), so it stays in the single-digit milliseconds even as the heap grows into hundreds of gigabytes.

Allocation rate drives pause frequency directly, not pause length: the young generation is a fixed-size buffer, and every allocation eats into it. A higher allocation rate (more objects created per second) fills that buffer faster, so minor GCs — each one a short STW pause — fire more often. Cutting allocation (reusing buffers, avoiding unnecessary boxing/autoboxing, streaming instead of materializing full collections) doesn't make an individual pause shorter, it makes pauses less frequent, which is usually what actually improves p99 latency, since most requests just need to avoid landing on a pause rather than needing the pause itself to be faster.

TLABs are why allocation itself doesn't need a lock, even under heavy multi-threaded load. Each thread gets its own small slice of the young generation — a Thread-Local Allocation Buffer — and a plain-object new is just bumping a pointer within that private slice, no synchronization required, which is what keeps allocation fast enough to sustain a high rate in the first place. A TLAB refill (the thread's slice is full, ask the JVM for a new one) is cheap and doesn't stop other threads. It's minor GC — reclaiming the whole young generation, TLABs included — that requires the STW pause, because that's the point where live objects need to be identified and copied while nothing else is allowed to mutate references. Tools like GCEasy or GCViewer parse the -Xlog:gc* output from the command above into charts specifically to make allocation-rate-vs-pause-frequency correlations like this visible at a glance instead of hand-counting log lines.

GC ergonomics is why most JVMs never need explicit tuning flags at all — on startup, the JVM inspects the machine's available memory and CPU count and auto-selects a default collector (G1 since JDK 9), initial/max heap size, and generation ratios meant to be reasonable for that hardware without any -XX flags. Tuning (a pause target, a region size, an allocation-reduction pass like the ones covered here) is what you reach for once ergonomics' generic defaults demonstrably don't fit a specific workload's latency or throughput requirements — not a starting assumption every production JVM needs from day one.

Keywords they're listening for: