HotSpot's Concurrent Mark-Sweep collector was deprecated in JDK 9 and removed entirely in JDK 14. If you owned a latency-sensitive service still pinned to an old JDK because of it, how would you reason about the migration and what would you expect to change operationally?

## Why the removal happened CMS was deprecated in JDK 9 and removed in JDK 14. The stated reasoning was maintenance economics rather than any single defect: CMS was a large, intricate, separately-maintained code path that complicated changes to the shared GC infrastructure, and nobody stepped forward to maintain it once G1 became the default. The technical case was already strong — a collector that never compacts carries a fragmentation-driven fallback to a long stop-the-world compacting full collection, which no amount of tuning eliminates. ## The decision to make The real question a service owner faces is not "which collector is best" but "what am I paying to stay where I am". Staying on a JDK old enough to have CMS means: - no security patches beyond that release's support window; - no runtime improvements — later JDKs bring compiler, startup, and footprint gains that often outweigh the collector difference; - an unbounded worst-case pause that remains one production traffic spike away. Against that, the migration cost is a tuning-and-validation exercise measured in days. Framed that way, the decision is straightforward; the engineering work is in doing it without a latency regression. ## Choosing the successor **G1 (region-based, the default)** is the right first target for nearly everyone. It preserves the parts of CMS that mattered — concurrent marking of the old generation, short root-scanning and fix-up pauses — and changes the reclamation strategy: the heap is divided into equal-sized regions, and collection *evacuates* live objects out of chosen regions into others, freeing each source region whole. Because evacuation is a copy, compaction is intrinsic to ordinary collection. Free memory therefore means allocatable memory, and the CMS fragmentation cliff simply does not exist in the steady state. G1 also takes a pause-time goal and adapts how many regions it collects per pause to meet it, which replaces much of the hand-tuning CMS demanded. **The concurrent-compaction collectors (ZGC, Shenandoah)** go further: they perform relocation concurrently using barriers, so pause times become largely independent of heap size. They are the answer when the requirement is genuinely single-digit-millisecond pauses on a large heap, and they cost some throughput and some footprint for it. Choose them from measured requirements, not aspiration. **The parallel throughput collector** remains the right answer for batch or throughput-bound workloads where pause time is not the constraint — worth stating explicitly, because a service that migrated off CMS may not have needed low-pause behaviour in the first place. ## How to run the migration **Delete the old flags.** There is no per-flag translation from a CMS configuration; the flags encode assumptions about in-place sweeping, initiating occupancy, and permanent generation that do not carry over. Carrying them forward at best produces warnings and at worst pins the new collector into a bad configuration. Start clean. **Start with a minimal configuration**: maximum heap size, and a pause-time goal. Resist adding knobs until measurement demands them. **Validate under production-shaped load.** GC behaviour is a function of allocation rate, promotion rate, object size distribution, and live-set size — a synthetic load test that misses any of these will mislead. Replay real traffic if you can, and run long enough to see steady state, not just warm-up. **Watch the right metrics.** Compare full pause distributions, not averages: p50, p99, p99.9, and maximum. Also compare CPU spent in GC, heap occupancy after collection, and allocation rate. The honest expected outcome is that G1's median pause may be a little higher than CMS at its best, while the tail is dramatically better because the fallback cliff is gone. **Re-tool the observability.** Modern JDKs use unified logging (`-Xlog:gc*`), whose records look nothing like the old CMS log lines. Any dashboard, alert, or log-parsing script keyed on CMS phase names must be rewritten, and pause thresholds recalibrated against the new distribution. This is routinely underestimated and is the most common source of post-migration noise. **Know the new failure modes.** G1 is not free of sharp edges: allocations of very large objects occupy contiguous *humongous* regions and can drive collection frequency, and G1 still has a stop-the-world full-GC fallback if it cannot keep up. The point is not that the fallback vanished, but that reaching it now requires genuine over-subscription rather than the slow accumulation of fragmentation. ## The judgment to articulate What an interviewer is listening for at this level is the reasoning frame: that a collector choice is a negotiation between pause-time targets, throughput, heap headroom, and operational simplicity; that the worst case, not the median, should drive capacity planning for a latency-sensitive service; and that migrating a runtime is a measurement exercise with a rollback plan, not a flag swap. The specific answer — move to the region-based collector, validate, escalate to a concurrent-compaction collector only if measurement shows you must — falls out of that frame.