G1GC vs CMS — Why G1 Replaced CMS as the Low-Pause Collector
Fast recall
Quick revision
Core answer
Whether you understand WHY G1 replaced CMS, not just that it did — specifically the fragmentation and concurrent-mode-failure pathologies of CMS
Thinking CMS is faster than G1 because it does less work per cycle (it isn't — CMS frequently triggers expensive concurrent-mode failures that fall back to a serial full GC)
Explain G1's incremental compaction and the remembered set mechanism, and why a region-based design enables a soft pause-time target that CMS cannot offer
Interview-ready guide
Interview answer
G1GC and CMS were both designed to reduce GC pause times compared to Parallel GC, but they took different architectural approaches — and CMS's choices ultimately led to its deprecation in Java 9 and removal in Java 14.
CMS — Concurrent Mark Sweep:
- Marks live objects concurrently with application threads — short stop-the-world pauses for marking phases
- Sweeps in place — does not compact the old generation
- Fragmentation builds up over time, eventually causing concurrent-mode failure
- When that happens, the JVM falls back to a single-threaded serial full GC that can take tens of seconds
G1GC — Garbage First:
- Divides the heap into hundreds of equal-sized regions (1-32MB each)
- Tracks garbage density per region; evacuates the highest-garbage regions first
- Compacts incrementally during evacuation — no fragmentation
- Soft pause-time target via
-XX:MaxGCPauseMillis=200— unique to G1; CMS had no equivalent
Why CMS was removed:
- Concurrent-mode failures were impossible to fully prevent and produced multi-second pauses that defeated the point of using a low-pause GC
- Maintaining two complex concurrent collectors was a burden on the OpenJDK team
- G1 had reached feature parity and offered better predictability
Migration practicalities:
- Replace
-XX:+UseConcMarkSweepGCwith-XX:+UseG1GC - Increase heap size by 10-20% — G1 needs more headroom
- Set a realistic pause-time target — lower values trade throughput for shorter pauses
- Monitor humongous allocations in the GC log
For modern low-latency needs, the answer is ZGC or Shenandoah — both achieve sub-millisecond pauses by performing nearly all work concurrently.
G1GC vs CMS — Why G1 Replaced CMS as the Low-Pause Collector
Direct Answer
G1 (Garbage-First) divides the heap into equal regions and collects the regions with the most garbage first, targeting a pause-time goal. CMS (Concurrent Mark Sweep) runs mostly concurrent mark/sweep on the old generation but suffers fragmentation and was removed in Java 14. G1 is the default from Java 9 onward; choose ZGC/Shenandoah for sub-10ms pause goals on large heaps.
Common Mistakes & Pitfalls
Thinking CMS is faster than G1 because it does less work per cycle (it isn't — CMS frequently triggers expensive concurrent-mode failures that fall back to a serial full GC)
Check your understanding
Answer these without looking back at the article.
- What is a 'humongous object' in G1GC and how does it affect collection?
- How does G1GC's remembered set track cross-region references?
- When would you choose ZGC over G1GC?
- What metrics in the GC log indicate that you should retune G1?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.