CMS and G1 Collectors: Low-Latency Garbage Collection

Serial and Parallel collectors are honest about what they are: stop-the-world collectors that freeze your application while they work. CMS and G1 take a different approach - they try to do some of their work concurrently, while your application is still running. The result is shorter pauses, but at the cost of complexity and CPU overhead.

This covers how CMS and G1 work, why G1 replaced CMS as the default, and what trade-offs you make when you choose either.

Introduction

CMS (Concurrent Mark Sweep) and G1 (Garbage First) are the JVM’s low-latency garbage collectors — designed to keep pause times short by performing most GC work concurrently with application threads rather than stopping the world. Serial and Parallel collectors freeze your application for the entire GC duration; CMS and G1 reduce pause times significantly by overlapping marking, sweeping, and compaction with your application’s execution. G1 replaced CMS as the default collector in Java 9 because CMS had fundamental reliability issues (floating garbage, fragmentation requiring fallback to Serial), but understanding both is essential for tuning older JVMs and reasoning about the design decisions that led to G1.

The key technical difference from older collectors is that both CMS and G1 use concurrent marking phases where application threads and GC threads run simultaneously, and G1 additionally divides the heap into equal-sized regions to enable incremental compaction and more predictable pause times. CMS uses free-list allocation which fragments memory and eventually requires a stop-the-world compaction; G1 uses a region-based layout that allows it to collect only the regions with the most garbage (“garbage first”) and compact incrementally. This post covers the internal mechanics of both, their failure modes, and the concrete scenarios where you would choose one over the other.

When to Use This Knowledge

Use when:

• Your application cannot tolerate multi-second GC pauses
• You have latency SLAs measured in hundreds of milliseconds
• Running server workloads where responsiveness matters (web servers, APIs, trading systems)
• You have heap sizes over 4GB where full stop-the-world GC becomes painful

Do not use when:

• Throughput is your only metric (batch processing, ETL)
• Your heap is small (under 1GB) and Serial/Parallel work fine
• You can already meet latency SLAs with Parallel GC

When NOT to Use This Knowledge

If your production environment runs ZGC or Shenandoah, most CMS and G1 tuning advice does not apply. These collectors work differently and require different approaches.

Java 21 LTS or later with strict latency SLAs? Start with ZGC. It eliminates pause time tuning complexity through automatic concurrent compaction. Time spent mastering G1 pause time targets when ZGC handles this automatically is opportunity cost wasted elsewhere.

CMS is gone, removed in Java 14. Learning CMS collector flags and failure modes is historical knowledge now unless you are maintaining legacy Java 8 systems. For new development, use modern collectors. For continued learning on modern JVM garbage collection, explore the Advanced Java & JVM Internals roadmap.

The Concurrent Approach

The core idea behind both CMS and G1 is simple: stop-the-world pauses are the enemy of latency. Instead of doing all GC work while the world is stopped, these collectors do as much work as possible concurrently - while application threads are running.

graph TB
    subgraph Serial["Serial/Parallel GC"]
        direction TB
        A1["Stop The World"] --> A2["GC Work"] --> A3["Stop The World"] --> A4["GC Work"]
    end
    subgraph Concurrent["CMS / G1"]
        direction TB
        B1["Initial Mark\n(STW - short)"] --> B2["Concurrent Mark"] --> B3["Remark\n(STW - short)"] --> B4["Concurrent Sweep"] --> B5["Concurrent Sweep"]
    end

The trade-off: doing GC work concurrently means using CPU cycles that could have gone to your application. You are buying shorter pauses with CPU time.

CMS Collector

CMS (Concurrent Mark Sweep) was the first low-latency collector in the JVM. It targets old generation GC, trying to collect it without long stop-the-world pauses.

How CMS Works

CMS phases:

1. Initial Mark (Stop-The-World, short): Mark reachable objects from GC roots. Fast - usually under 100ms.

2. Concurrent Mark: Traverse the object graph while application runs. Takes time but does not stop the world.

3. Remark (Stop-The-World, short): Finalize marking of objects modified during concurrent phase (the “floating garbage” problem).

4. Concurrent Sweep: Reclaim unmarked objects while application runs.

5. Concurrent Reset: Prepare CMS data structures for next cycle.

graph TB
    A["Initial Mark\n(STW)"] --> B["Concurrent Mark\n(app running)"]
    B --> C["Remark\n(STW)"]
    C --> D["Concurrent Sweep\n(app running)"]
    D --> E["Concurrent Reset"]
    E --> A

Floating Garbage

CMS concurrent marking is imprecise. Objects that become unreachable during concurrent marking (modified by application threads) may not be reclaimed - they are called “floating garbage.” This garbage sits in the heap until the next CMS cycle.

This is a fundamental limitation of concurrent marking: you cannot stop the application while doing the full mark, so some objects slip through.

CMS accumulates floating garbage because of how its two-phase marking works. Initial mark grabs everything reachable at the start. Then concurrent mark walks the object graph while your app runs. During that walk, your app threads change object references — objects can slip from reachable to unreachable — but concurrent mark does not see those changes. The remark phase catches some of them, but not all. That gap is the floating garbage window.

Whether it matters depends on your allocation rate. A low-traffic service churning through 100MB of floating garbage per cycle will probably never notice. A high-throughput system pushing gigabytes per minute can fill old generation between CMS cycles, which triggers a concurrent mode failure. You can shrink the window by lowering -XX:CMSInitiatingOccupancyFraction so CMS kicks in earlier, but that costs more CPU.

G1 takes a different approach. Its snapshot-at-the-beginning (SATB) algorithm marks objects that were live when marking started, treating anything modified during marking as live even if it would have become unreachable. This is faster but leaves more floating garbage behind. G1 makes up for it through cleanup phases that reclaim regions with high garbage density, so the heap does not fill up as fast.

Key Characteristics

Aspect	Behavior
GC threads	Multiple + concurrent
Pause time	Short pauses for Initial Mark and Remark
Throughput	Lower than Parallel - concurrent phases use CPU
Old gen collection	Mostly concurrent
Young gen collection	Serial or Parallel Copying
Heap fragmentation	Moderate - no compaction by default
Deprecated	Removed in Java 14 (replaced by G1)

CMS Failure Modes

CMS can fail in two main ways:

1. Concurrent Mode Failure: CMS cannot finish collecting before old generation fills up. Triggers a full stop-the-world GC as fallback.

2. Promotion Failure: Object in young generation cannot fit in old generation during minor GC, triggering full GC.

Both failures come down to memory pressure, but the mechanism differs. Concurrent mode failure is a slow burn — CMS falling behind over multiple cycles. Promotion failure is an acute event during a specific minor GC. If you are hitting concurrent mode failure, lower -XX:CMSInitiatingOccupancyFraction or add more heap. If promotion is failing, increase old generation reservations or shrink the young generation to reduce individual promotion sizes.

JVM Flags for CMS

-XX:+UseConcMarkSweepGC
-XX:ParallelCMSThreads=N     # CMS threads (default: (ncpus+3)/4)
-XX:CMSInitiatingOccupancyFraction=70  # Start CMS when old gen 70% full
-XX:+UseCMSInitiatingOccupancyOnly   # Always trigger at the threshold

-XX:+UseConcMarkSweepGC enables CMS — without it, none of the other flags matter. -XX:ParallelCMSThreads sets the number of threads for concurrent phases; the default formula (ncpus+3)/4 is reasonable for most workloads, but CPU-bound applications may benefit from matching the thread count to actual GC-to-app thread ratio. -XX:CMSInitiatingOccupancyFraction is the most impactful tuning knob — it controls when CMS starts a cycle based on old generation occupancy percentage. The default of 70% gives maximum time for concurrent work but leaves little headroom if your allocation rate is high. For latency-sensitive workloads, 60% or even 50% is often safer — CMS starts earlier but has more breathing room to finish before old gen fills. The catch is that lower occupancy means more frequent CMS cycles, which burns more CPU. -XX:+UseCMSInitiatingOccupancyOnly forces CMS to always trigger at the exact threshold rather than letting it adaptively adjust based on past behavior. Set this when you want deterministic triggering and are willing to give up CMS’s self-tuning.

One flag worth knowing but not shown here: -XX:+UseCMSCompactAtFullCollection. CMS does not compact at the end of a concurrent cycle — compaction only happens during a Full GC. This flag forces compaction at the end of a Full GC, which reduces fragmentation but adds a stop-the-world pause. If you are already accepting Full GC pauses and want to reduce fragmentation for the next cycle, this helps. On Java 8 it is on by default; on later versions it is not. On Java 8 you can also set -XX:CMSFullGCsBeforeCompaction=N to trigger compaction after N Full GCs rather than every one — trading some fragmentation for fewer long pauses.

G1 Collector

G1 (Garbage First) replaced CMS as the default collector in Java 9. It takes a fundamentally different approach: instead of treating the heap as one contiguous space, it divides the heap into many equal-sized regions.

graph TB
    subgraph G1Heap["G1 Heap - Divided into Regions"]
        direction TB
        R1["Region 1\n(Eden)"]
        R2["Region 2\n(Survivor)"]
        R3["Region 3\n(Old)"]
        R4["Region 4\n(Old)"]
        R5["Region 5\n(Eden)"]
        R6["Region 6\n(Humongous)"]
    end

How G1 Works

G1 divides the heap into regions of equal size (typically 1MB to 32MB depending on heap size). Each region can be Eden, Survivor, or Old generation - the designation is fluid and changes between GC cycles.

G1 tracks live object density per region. During a GC, it collects regions with the most garbage first - hence “Garbage First.”

graph TB
    subgraph G1Cycles["G1 GC Cycles"]
        A["Young GC\n(Copying - STW)"] --> B["Concurrent Mark\n(regions)"]
        B --> C["Mixed GC\n(Evacuate old regions - STW)"]
        C --> A
    end

G1 GC Phases

1. Young GC (Stop-The-World): Copy live objects from young regions to survivor regions or promotes to old regions. Uses multiple threads.

2. Concurrent Marking: Like CMS, G1 performs concurrent marking to identify live objects across all regions. Runs in background threads.

3. Remark (Stop-The-World): Like CMS, finalizes marking of objects modified during concurrent phase.

4. Mixed GC: After concurrent marking, G1 may collect a mix of young and old regions. G1 selects regions with lowest live ratio first.

5. Cleanup: Frees completely empty regions, updates remembered sets.

Why G1 Replaced CMS

Aspect	CMS	G1
Heap division	Contiguous	Regions
Compaction	None by default (fragmentation)	Incremental (per-region)
Full GC	Falls back to Serial/Parallel	G1 handles it
JDK support	Removed in Java 14	Default since Java 9
Large heaps	CMS struggles >4GB	Scales well to large heaps
Predictability	Poor (no pause target)	Good (pause time target configurable)

G1’s region-based design lets it compact incrementally - it does not need to compact the entire old generation at once. This makes pause times more predictable and manageable.

Pause Time Target

G1 lets you set a target for maximum GC pause time:

-XX:MaxGCPauseMillis=200    # Target 200ms max pause

G1 then tunes its collection to try to meet this target. Note: this is a target, not a guarantee. Under memory pressure, G1 may not be able to meet it.

G1 estimates how long each region takes to collect based on live object density and past pause times. When you set MaxGCPauseMillis, G1 builds its collection set (CSet) by adding regions in garbage-density order until the estimated pause time would hit the target. It stops there, leaving the rest for the next cycle. G1 is always garbage-first, so it collects the most garbage per unit time within your latency budget.

When G1 cannot meet the target, allocation pressure has outpaced its ability to collect fast enough. G1 still triggers a young GC to avoid heap exhaustion, but the pause overshoots the target. The next cycle tries to collect more regions. If pauses keep exceeding the target, you can increase heap size, relax the target, or reduce garbage production by sizing the young generation down.

Setting MaxGCPauseMillis too low backfires. On a heavily-loaded system, 50ms forces G1 to collect tiny batches constantly, which burns more CPU on GC overhead and leaves less for your application. Most web services land in the 100-300ms range. Batch workloads can go higher.

Key Characteristics of G1

Aspect	Behavior
GC threads	Multiple + concurrent
Pause time	Configurable target via MaxGCPauseMillis
Throughput	Lower than Parallel GC (concurrent phases use CPU)
Heap layout	Region-based (1MB to 32MB regions)
Compaction	Incremental per-region
Young gen	Dynamic - size adjusts between Min and Max
Large objects	Humongous regions handle objects > 50% of region size

JVM Flags for G1

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200    # Target max pause time
-XX:G1HeapRegionSize=N      # Region size (1MB, 2MB, 4MB, 8MB, 16MB, 32MB)
-XX:InitiatingHeapOccupancyPercent=45  # Start GC when heap 45% full
-XX:G1ReservePercent=10     # Reserve 10% for promotion failures

Production Failure Scenarios

1. G1 Evacuation Failure

Symptom: GC pause for evacuation failure or to-space exhausted. Application freezes.

Cause: G1 ran out of free regions to copy survivor objects into. Happens when the to-space (target regions) fills up during a young or mixed GC.

Solution:

# Increase reserve space
-XX:G1ReservePercent=15

# Increase heap if possible
-Xms4g -Xmx4g

# Reduce expected pause time if target is too aggressive
-XX:MaxGCPauseMillis=500

2. CMS Concurrent Mode Failure

Symptom: CMS cannot complete before old generation fills. Full GC kicks in and freezes application.

Cause: Old generation filling faster than CMS can reclaim it. Usually means you need more heap, lower CMSInitiatingOccupancyFraction, or a different collector.

Solution:

# Start CMS earlier
-XX:CMSInitiatingOccupancyFraction=60

# Or just switch to G1
-XX:+UseG1GC

3. Humongous Object Issues (G1)

Symptom: Frequent long pauses with many humongous allocations.

Cause: Objects larger than half a G1 region (e.g., > 16MB with 32MB regions) are treated as “humongous” and collected differently. They can cause fragmentation in the humongous region space.

Solution:

# Increase region size if heap is large
-XX:G1HeapRegionSize=32m

# Avoid allocating very large buffers in hot paths

Trade-off Table

Configuration	When to use	Trade-off
-XX:+UseConcMarkSweepGC	Legacy systems, Java 8 with low-latency needs	Deprecated, no compaction, can fail badly
-XX:+UseG1GC	Default for most low-latency workloads	More CPU overhead than Parallel GC
-XX:MaxGCPauseMillis=100	Strict latency SLA	May reduce throughput if too aggressive
-XX:G1HeapRegionSize=16m	Large heaps (>16GB)	Smaller regions = more regions to manage
-XX:CMSInitiatingOccupancyFraction=70	Tune CMS trigger point	Too low = premature collections, too high = failure

Implementation Snippets

Checking Which Collector Is Running

import java.lang.management.*;
import java.util.*;

public class CollectorCheck {
    public static void main(String[] args) {
        List<GarbageCollectorMXBean> gcs = ManagementFactory.getGarbageCollectorMXBeans();
        for (GarbageCollectorMXBean gc : gcs) {
            System.out.println("Collector: " + gc.getName());
            System.out.println("  Cycles: " + gc.getCollectionCount());
            System.out.println("  Time: " + gc.getCollectionTime() + "ms");
        }
    }
}

Enabling G1 and Setting Pause Target

java -XX:+UseG1GC \
     -XX:MaxGCPauseMillis=150 \
     -XX:G1HeapRegionSize=16m \
     -XX:InitiatingHeapOccupancyPercent=45 \
     -Xms4g -Xmx4g \
     -Xlog:gc*:file=g1.log \
     -jar myapp.jar

Reading G1 GC Logs

G1 logs break down pause time by phase, making it easier to identify bottlenecks. Each pause entry tells you which type of GC ran, how much memory moved, and how long each sub-phase took.

[GC pause (G1 Evacuation Pause) 256M->245M(4G) 148.734ms]
[Ext Root Scanning: 23.4ms]
[Update RS: 12.1ms]
[Scan RS: 8.3ms]
[Object Copy: 89.2ms]

Each field in a pause log entry maps to something specific:

• G1 Evacuation Pause — Young or mixed GC where G1 copies live objects from one set of regions to another. This is a stop-the-world event.
• 256M->245M(4G) — Heap usage before and after the pause, and total heap size. In this case 256MB in use before, 245MB after, across a 4GB heap.
• 148.734ms — Total pause duration. Compare this against your -XX:MaxGCPauseMillis target.

The indented sub-lines are phase timings:

Phase	What it does
Ext Root Scanning	Scans GC roots (thread stacks, object headers, JNI references)
Update RS	Updates remembered sets for regions whose references changed
Scan RS	Scans remembered sets for references pointing into the CSet
Object Copy	Copies live objects from source regions to target regions

The phase timings add up to the total pause time. If Object Copy dominates, your young generation is too large or survival rate is high — G1 is spending most of its time moving objects. If Ext Root Scanning dominates, you have many threads with deep stacks or a lot of JNI code.

Other common log entries to watch for:

[Concurrent Mark]
[GC pause (G1 Humongous Allocation)]
[GC pause (G1 Cleanup)]
[Full GC]

Concurrent Mark runs in the background, no pause. Humongous Allocation pauses are brief but frequent ones point to large buffers being created in your hot path. Cleanup has a stop-the-world component for resetting region tables. Full GC means G1 fell back to serial compaction, which can take seconds on large heaps.

Use -Xlog:gc*=debug for full phase breakdowns during development, then switch to -Xlog:gc*:file=g1.log in production to capture enough detail without overwhelming log storage.

Observability Checklist

• Enable GC logging: -Xlog:gc*:file=g1.log or -Xlog:gc*:file=cms.log
• Monitor pause times from GC logs - look for pauses exceeding your target
• Track jstat -gc <pid> for OC (old gen capacity) vs OU (old gen used)
• Watch for evacuation failures in G1 logs: to-space exhausted
• Monitor CMS concurrent mode failure events
• For G1: check G1HeapRegionSize is appropriate for your heap size
• Use -XX:PrintGCDetails for phase-level timing breakdown

Security Notes

1. Concurrent phases use more CPU, which can reveal allocation patterns through timing side channels
2. GC logs expose memory usage patterns and object lifetime characteristics
3. JMX access to GC beans should be restricted - can reveal collector internals and tuning
4. Large heaps mean larger heap dumps on OOM - more data to protect

Common Pitfalls / Anti-Patterns

Pitfall	What happens	Fix
Setting pause target too low	G1 uses too much CPU trying to meet target	Increase MaxGCPauseMillis or add more heap
Using CMS on Java 11+	Removed from JDK	Migrate to G1
Ignoring G1 region size	Suboptimal performance on large heaps	Set G1HeapRegionSize explicitly
Too small G1ReservePercent	Evacuation failures	Increase to 15-20
Setting old gen threshold too high (CMS)	Concurrent mode failure	Lower CMSInitiatingOccupancyFraction

Quick Recap Checklist

• CMS = concurrent mark-sweep, deprecated in Java 14, no compaction
• G1 = region-based, incremental compaction, default since Java 9
• Both do work concurrently to reduce pause times
• Concurrent phases use CPU that could go to your application
• G1 pause target set via -XX:MaxGCPauseMillis=N
• G1 divides heap into 1MB-32MB regions
• CMS fallback: concurrent mode failure triggers full stop-the-world
• For Java 11+, use G1 - CMS is gone

Interview Questions

Further Reading

• GC Fundamentals: Mark-Compact, Copying, and Mark-Sweep — Internal link to related roadmap blog
• Serial vs Parallel GC: Throughput-Focused Collectors — Internal link to related roadmap blog
• Oracle Java Docs: G1 Garbage Collector — Official G1 tuning guide
• Red Hat Developer: Understanding G1 GC Logs — Guide to interpreting G1 output
• Advanced Java & JVM Internals Roadmap — Parent roadmap

Conclusion

CMS achieves low-latency through concurrent marking and sweeping, but lacks compaction and is deprecated. G1 replaced CMS as the default by dividing the heap into regions and performing incremental compaction — it collects garbage-first regions to meet pause time targets. CMS is removed in Java 14+; use G1 for low-latency workloads on Java 9-13, and consider ZGC or Shenandoah for strict sub-millisecond SLA requirements.