G1 Garbage Collector

G1 (Garbage-First) is a Java garbage collector that divides the heap into regions and selects collections based partly on how much reclaimable memory each region offers. It is designed to provide predictable pause-time behavior while continuing to reclaim memory efficiently.

G1 partitions the Java heap into many equal-sized regions rather than treating the heap as a small number of contiguous generations. Objects are allocated into regions, while regions can serve as young-generation or old-generation storage as the collector manages the heap.

G1 performs concurrent marking to determine which old regions contain substantial amounts of live data versus reclaimable space. During a collection pause, it can prioritize regions that offer more expected garbage reclamation for the available pause budget; this is the basis of the name Garbage-First.

Young collections evacuate live objects from selected regions into other regions. Because live objects are copied rather than individually swept in place, G1 can compact the heap incrementally and reduce long-term fragmentation. Mixed collections can additionally include selected old regions after marking has identified candidates for reclamation.

G1 uses a pause-time target as a goal rather than an absolute guarantee. If the application specifies a target with `-XX:MaxGCPauseMillis`, the collector uses that target when planning work, but actual pauses can differ because of allocation rates, heap occupancy, object survival, remembered-set work, and other runtime conditions.

Key points

• The heap is divided into equal-sized regions.
• G1 uses concurrent marking to identify reclaimable old regions.
• Collections prioritize regions with high expected garbage reclamation.
• Evacuation copies live objects and provides incremental compaction.
• `MaxGCPauseMillis` is a target, not a guaranteed maximum pause.

Interview questions

How does G1 divide and manage the heap?

G1 divides the heap into many equal-sized regions. Regions can be used for different purposes as the collector manages the young and old parts of the heap. Instead of requiring the old generation to be one contiguous area, G1 can select individual regions for collection. This lets it choose work incrementally.

What does 'Garbage-First' mean in G1?

G1 estimates how much garbage can be reclaimed from candidate regions and prioritizes regions that offer substantial reclamation for the available collection effort. This lets it focus a pause on useful work instead of necessarily scanning every old region. The selection is tied to G1's pause-time planning. The goal is efficient reclamation while keeping pauses within the desired range.

Is `MaxGCPauseMillis` a guarantee?

No. It is a target that G1 uses when planning garbage-collection work. Actual pauses can exceed the target because runtime conditions such as allocation rate, object survival, remembered-set processing, and available CPU resources affect the work required. Therefore, production tuning should examine observed GC behavior rather than treating the setting as a strict deadline.

What is the difference between a young collection and a mixed collection in G1?

A young collection primarily collects regions belonging to the young generation and evacuates surviving objects. After concurrent marking identifies suitable old regions, G1 can perform mixed collections that include selected old regions in addition to young regions. This allows old-generation garbage to be reclaimed incrementally rather than requiring one full old-generation collection. The selection is constrained by G1's collection planning.

Why can G1 reduce fragmentation?

G1 generally reclaims memory by evacuating live objects from selected regions into other regions. Moving survivors together leaves the evacuated regions available for reuse, rather than simply leaving holes throughout an old-generation area. Because this compaction happens incrementally as part of region evacuation, G1 can manage fragmentation without requiring every collection to compact the entire heap. The trade-off is that evacuation requires CPU and memory bandwidth for copying live objects.