Walk through the phases of one garbage-collection cycle in HotSpot's Shenandoah collector, and state precisely which parts stop the application threads.

## The shape of a cycle Shenandoah's cycle is best remembered as three concurrent workloads — **mark**, **evacuate**, **update references** — each fenced by short stop-the-world points that exist only to take a consistent snapshot of the roots or to flip global state safely. Nothing in a pause is proportional to heap size or live data. ## 1. Pause Init Mark (stop-the-world) All threads reach a safepoint. The collector scans the roots — thread stacks and registers, static fields, JNI handles — marking the objects they reference and queuing them for tracing. It also flips a global GC state word that each thread reads, which activates the barriers in compiled code. Duration is proportional to the number and depth of thread stacks, so a process with thousands of threads has measurably longer init-mark pauses than one with a handful. ## 2. Concurrent Mark Application threads resume; collector threads trace the object graph from the marked roots. Because the application keeps mutating references during the trace, the collector could otherwise miss an object that gets moved from an untraced location to an already-traced one. Shenandoah handles this with a **snapshot-at-the-beginning** write barrier: when the application overwrites a reference field, the previous value is recorded into a thread-local buffer so the collector still traces it. The effect is that the collector marks everything live at the start of the cycle, plus anything allocated during it — newly allocated objects are treated as live for this cycle and considered next time. This is the longest phase in most cycles, and its cost scales with live data. ## 3. Pause Final Mark (stop-the-world) Another safepoint. The collector drains the SATB buffers, completes marking, and then does the planning work for the rest of the cycle: - compute how much live data each region holds; - select the **collection set**: the regions whose evacuation yields the most free space for the least copying; - pre-allocate the regions evacuation will copy into; - evacuate the objects directly referenced from roots, so that after the pause every root already satisfies the to-space invariant. Again, the pause cost tracks roots and buffers, not the heap. ## 4. Concurrent Cleanup (immediate garbage) Regions found to contain **no** live objects are recycled straight away without copying anything. On workloads where most objects die young this is a large share of the reclaimed memory and is essentially free. ## 5. Concurrent Evacuation Collector threads copy live objects out of the collection set into the newly allocated regions. Simultaneously, application threads that load a reference into the collection set may copy the object themselves via the load reference barrier, and they self-heal the field they loaded from. Two threads racing to copy the same object are resolved by a compare-and-swap on the forwarding word. This is the phase that makes the collector unusual: compaction, historically a stop-the-world operation, is happening while requests are being served. ## 6. Pause Init Update Refs (stop-the-world) A very short checkpoint — often a fraction of a millisecond. It mostly ensures every thread has finished its evacuation work and flips state before the reference-updating phase begins. ## 7. Concurrent Update References The collector walks the heap linearly, rewriting any references that still point into evacuated regions so they point at the to-space copies. Much of this work has already been done opportunistically by self-healing barriers during evacuation; this phase guarantees completeness. It scales with live data, not with the collection set. ## 8. Pause Final Update Refs (stop-the-world) Update the remaining roots (which can only be fixed at a safepoint), then recycle the collection-set regions — their contents are now unreachable because every reference has been rewritten. ## 9. Concurrent Cleanup The freed regions are returned to the allocator, and their space becomes available for allocation. ## Reading it in a log With `-Xlog:gc` each phase appears on its own line, pauses labelled `Pause …` and concurrent phases labelled `Concurrent …`. The habit worth building is to check (a) that pauses stay sub-millisecond to low-single-digit milliseconds, (b) that concurrent phases complete before the heap fills, and (c) that no lines say `Pause Degenerated GC` or `Pause Full` — those indicate the collector lost the race against allocation and had to finish the work with the world stopped. ## Why the phase list is worth memorising Because every operational question maps onto it: long pauses ⇒ look at the root set (thread count, stack depth); long cycles that do not keep up ⇒ look at allocation rate, heap headroom, and concurrent thread count; degenerated GCs ⇒ the cycle started too late for the allocation rate. The phase names in the log are the diagnostic vocabulary.