HotSpot's Concurrent Mark-Sweep collector (CMS) performed most of its old-generation marking while application threads kept running. Walk through the phases of one of its old-generation cycles and say which of them stopped the world.

## What CMS was for Before CMS, an old-generation collection meant tracing the whole old generation with the application stopped, so the pause scaled with live-set size — seconds on a multi-gigabyte heap. CMS's bet was that most of that tracing could run *concurrently with the application*, leaving only two short stop-the-world phases. It was a generational collector: the young generation was collected by a separate parallel copying collector (ParNew) with ordinary stop-the-world pauses, and CMS handled only the old generation. ## The phases in detail **Initial mark (stop-the-world).** The collector needs a starting set. It marks objects directly reachable from thread stacks, static fields, and other roots, plus objects in the old generation referenced from the young generation. This is a shallow scan, so the pause is short — though it grows if the young generation is large and full of references into the old generation, which is why the collector preferred to run it right after a young collection. **Concurrent mark.** Marking threads trace the reachable graph from the initial set while application threads keep mutating it. This is the phase that buys the low pause: the expensive transitive walk is overlapped with useful work. It also creates the central problem — the heap is changing underneath the marker, so the mark can become wrong. A write barrier records mutations (by dirtying the card containing the modified object) so they can be revisited. **Preclean and abortable preclean.** These concurrent phases process the mutation record that accumulated during marking, shrinking the work left for the pause that follows. The *abortable* variant additionally waits, up to a time limit, for a young collection to happen — remark right after a young collection has far fewer young objects to scan, so scheduling matters. **Final remark (stop-the-world).** Everything that changed during concurrent marking has to be reconciled with the application stopped, otherwise the collector could free a live object. Remark re-scans roots and dirty cards and finishes the marking. This was typically the longest CMS pause — not close to a full-GC pause, but sensitive to young-generation size and mutation rate, which is why remark times were the first thing to look at when CMS pauses grew. **Concurrent sweep.** Unmarked objects are reclaimed and their space is returned to **free lists**. Crucially, live objects are **not moved**. That choice is what makes sweeping concurrent-safe — no application thread can hold a reference that the collector is about to invalidate — and it is also the origin of CMS's defining weakness, fragmentation. **Concurrent reset.** Marking state is cleared, ready for the next cycle. ## What "concurrent" did and did not buy It is worth being precise about the tradeoffs, because interviewers probe them: - **Pauses got shorter, not fewer.** Young collections were still fully stop-the-world, and the two CMS pauses were added on top of them. - **Throughput went down.** Marking threads compete with the application for CPU, and the write barrier adds cost to every reference store. On a CPU-saturated machine, giving cycles to the collector directly slows the application — CMS traded throughput for latency by design. - **Floating garbage.** Objects that die *after* being marked in a concurrent cycle are not collected until the next cycle, so the heap must carry that extra headroom. - **Allocation got slower.** Because free space lives in free lists rather than one contiguous block, old-generation allocation and promotion involve free-list management rather than a pointer bump. ## Reading the log CMS logs named its phases explicitly — `CMS-initial-mark`, `CMS-concurrent-mark`, `CMS-concurrent-abortable-preclean`, `CMS Final Remark`, `CMS-concurrent-sweep` — with concurrent phases showing both CPU time and wall time. Two numbers mattered: the durations of the two stop-the-world phases, and whether cycles were completing before the old generation filled. ## Why the design is still worth knowing CMS was deprecated in JDK 9 and removed in JDK 14, so you will not tune it on a new service. It is asked about because its structure is the ancestor of everything that followed: a short root-scanning pause, a concurrent trace, a fix-up pause, and a reclamation phase is exactly the skeleton of the region-based G1 collector, and the later fully-concurrent collectors are best understood as answers to the specific weaknesses CMS exposed — above all, that a collector which never compacts eventually loses to fragmentation.