Mastering Java CMS GC: How It Works, When It Triggers, and Tuning Tips

Introduction

The article lists common questions about the CMS (Concurrent Mark‑Sweep) garbage collector and aims to answer them.

Fundamental concepts

CMS is a mostly‑concurrent collector that handles the old generation while using the same young‑generation strategy as Parallel and Serial collectors. Its purpose is to eliminate long pauses caused by the Throughput and Serial collectors during Full GC.

Suitable scenarios: applications requiring low latency and having sufficient CPU resources.

CMS lifecycle

Initial Mark (STW) : Marks objects reachable directly from GC roots and old‑generation objects referenced from the young generation (single‑threaded).

Concurrent Mark : Traces reachable objects while application threads run; objects promoted or references changed are recorded in dirty cards.

Pre‑clean : Marks live objects in the old generation to shorten the subsequent remark pause. It scans dirty cards and references from survivor spaces.

Abortable Pre‑clean : May run repeatedly; exits when CMSMaxAbortablePrecleanLoops or CMSMaxAbortablePrecleanTime limits are reached.

Remark (STW) : Re‑scans the heap to finalize reachability, covering young‑generation objects, GC roots, and dirty cards.

Concurrent Sweep : Re‑activates application threads and reclaims unmarked objects.

Concurrent Reset : Prepares the collector for the next cycle.

Abnormal situations

Concurrent mode failure – when allocation in the old generation exceeds the reserved space, causing a Full GC.

Promotion failure – insufficient space for objects promoted from the young generation.

Metaspace (PermGen) exhaustion – triggers Full GC because CMS does not collect metaspace by default.

Tuning CMS

Identify the phase causing long pauses and adjust parameters accordingly.

Increase old‑generation size or reduce young‑generation size.

Increase the frequency of concurrent cycles by lowering CMSInitiatingOccupancyFraction (but not too low).

Increase the number of GC threads: (CPU cores + 3) / 4.

Enable UseCMSCompactAtFullCollection and CMSFullGCsBeforeCompaction to mitigate fragmentation.

Enable CMSPermGenSweepingEnabled and CMSClassUnloadingEnabled for metaspace collection.

Trade‑offs

Advantages: Low latency, short pauses during minor GC and concurrent phases.

Disadvantages: Higher CPU usage, possible heap fragmentation, larger heap requirement, and occasional Full GC.

FAQ

ParNew works with CMS because both are built on the generational framework; Parallel Scavenge is not.

Minor and major GC can interleave during a CMS cycle.

CMS triggers when old‑generation usage reaches a threshold (default ~92%) or when dynamic heuristics predict imminent exhaustion.

CMS scans the entire heap for GC roots, using the card table to track references between generations.

Recommended JVM options

-Xmx4096M -Xms4096M -Xmn1536M
-XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M
-XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=70
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:+CMSClassUnloadingEnabled -XX:+ParallelRefProcEnabled
-XX:+CMSScavengeBeforeRemark -XX:ErrorFile=... -Xloggc=...
-XX:HeapDumpPath=... -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-XX:+HeapDumpOnOutOfMemoryError

References

From real‑case Java application GC optimization

Understanding CMS GC logs

Introduce to CMS Collector

Deep dive into Java Virtual Machine

Oracle GC tuning guide