G1 GC Overview - What Problem It Solves

G1 (Garbage-First) is a low-latency, region-based collector. It divides the heap into regions and prioritizes collecting regions with the most garbage, aiming to meet a configurable pause-time target (e.g. 10ms). Suited for large heaps (e.g. 4GB+) and when you need predictable pauses. This article explains G1's design, flow, and key parameters with examples and a comparison table.

Overview

• Goal: Maximize throughput while meeting a pause-time target (-XX:MaxGCPauseMillis). By collecting the "garbage-first" regions, G1 shortens individual pauses.
• Regions: The heap is divided into equal-sized regions (typically 1–32MB). Young and Old are sets of regions. A region holds only Young or Old; Humongous regions hold objects larger than half a region.
• Flow: Young GC collects Young regions. Mixed GC collects Young plus a selection of Old regions based on the pause budget. Full GC can still occur (e.g. promotion failure, fragmentation) and should be minimized through tuning.

Example

Example 1: Typical G1 options

Plain textCopy
-XX:+UseG1GC
-Xmx4g -Xms4g
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=4m

• 4 GB heap, 200 ms pause target, 4 MB regions. G1 tries to complete each Young/Mixed GC within 200 ms.

Example 2: Young GC and Mixed GC

• Young GC: Triggered when Eden regions are full. Live objects are copied to Survivor or promoted to Old. STW; usually short.
• Mixed GC: After Young GC, if Old occupancy exceeds a threshold (-XX:InitiatingHeapOccupancyPercent, default 45), concurrent marking starts. Then G1 selects a set of Old regions to collect together with Young. The number of regions is chosen to stay within the pause target.

Example 3: Humongous objects

• Objects larger than half a region go into Humongous regions. They can cause allocation and promotion overhead. Consider chunking large arrays or using off-heap storage to reduce Humongous usage.

Example 4: Collector comparison

Feature	Parallel	CMS	G1
Goal	Throughput	Low pause (concurrent Old)	Configurable pause, large heap
Pause	Can be long	Old concurrent, but Full GC can be long	Target-driven
Typical use	Batch, throughput-first	Concurrent Old (deprecated)	Large heap, low-latency default

Core Mechanism / Behavior

• Concurrent marking: Marking runs concurrently with the mutator. Write barriers record reference changes (G1 uses SATB). A short STW "Final Remark" finishes marking.
• Region selection: G1 picks regions by reclaimable space and copy cost to maximize collection within the pause budget.
• Humongous: Objects > half a region occupy whole regions. Too many Humongous objects can hurt efficiency. Tune -XX:G1HeapRegionSize or reduce large allocations.

Key Rules

• Prefer G1 for large heaps (e.g. ≥4 GB) when you need bounded pauses. Set -XX:MaxGCPauseMillis to an acceptable value (e.g. 100–200 ms).
• Avoid too many Humongous objects: chunk large arrays or use off-heap storage.
• Use GC logs (-Xlog:gc*) to observe Young/Mixed/Full frequency and pauses. Combine with GC Tuning and OOM Playbook when Full GC is frequent.

What's Next

See GC Tuning Principles for tuning. See OutOfMemoryError Playbook for heap and Metaspace OOM. See GC Basics for Minor/Full GC concepts.