Java › Garbage Collection
What is the difference between a stop-the-world (STW) GC pause and a concurrent GC phase, and why can't garbage collection be made entirely concurrent with zero pauses?
IntermediateAnswer
A stop-the-world pause completely suspends ALL application threads while the GC performs certain operations that require a stable, unchanging view of the heap and all object references (most notably, the initial root-scanning phase that identifies the starting set of GC roots, and typically the final compaction/relocation phase that physically moves surviving objects to defragment memory) -- while modern collectors like G1/ZGC/Shenandoah perform the bulk of marking and even much of the relocation work CONCURRENTLY alongside running application threads (using techniques like write barriers and read barriers to handle concurrent mutation safely), completely eliminating STW pauses remains extremely difficult since certain coordination points (like establishing a consistent initial root set, or briefly pausing to finalize a relocation) fundamentally benefit from or require a moment of full synchronization across all threads, which is why even the most advanced low-latency collectors still have brief (though very short) STW pauses rather than zero pauses entirely.
# GC log output distinguishing pause types (illustrative, actual format varies by collector/JVM version)
# [gc,phases] GC(42) Pause Young (Normal) (G1 Evacuation Pause) 45M->12M(128M) 8.2ms <- STW pause
# [gc,phases] GC(42) Concurrent Mark Cycle <- runs alongside application threads, no full pauseReal-world example A latency-sensitive application monitoring its GC logs observes that even with ZGC configured, brief sub-millisecond STW pauses still occur periodically for root-scanning coordination, confirming that 'concurrent' garbage collection significantly reduces but doesn't entirely eliminate stop-the-world pauses, an important distinction when setting realistic latency expectations.