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.

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.

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

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.

Key Characteristics

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

[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]

G1 logs break down pause time by phase, making it easier to identify bottlenecks.

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

• G1: The Garbage-First Collector - Original paper from Dehesh, Owens, and Upton on G1 design
• Understanding G1 GC Logs - Red Hat guide to interpreting G1 output
• Java 9 G1 as Default GC - Migration Guide - Practical guide for switching to G1
• CMS to G1 Migration - AWS guidance on moving from deprecated CMS

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.