How G1 GC Works — Regions, Mixed Collections & Humongous Objects

MaxGCPauseMillis is a soft target, not a hard guarantee. G1 tracks how much garbage each region yields per unit of collection time, and before every collection it picks however many regions it estimates it can collect within the pause target — it literally sizes the work to fit the time budget, region by region, rather than committing to a fixed collection set up front. Set the target too low and G1 shrinks the collection set to compensate, which means it reclaims less garbage per pause and has to run pauses more often — 'lower pause target' can paradoxically mean more total time spent pausing, not less.

Humongous objects are costly for two compounding reasons. First, any object bigger than half a region size is allocated directly into a run of contiguous free regions (skipping the normal young-gen allocation path entirely), which can force an otherwise-unnecessary GC just to free up that much contiguous space. Second, those humongous regions live in old gen from birth and are only reclaimed during a full region-emptying collection — they can't be partially collected the way normal old regions can during a mixed GC, so a large array that becomes garbage still sits there, uncollected, until G1 does a collection that happens to fully empty its region.

Tuning G1HeapRegionSize: because the humongous threshold is defined as half a region, the practical fix for frequent humongous allocations is usually raising the region size itself (-XX:G1HeapRegionSize=32m, for example) so the objects triggering it no longer cross that 50% line — not shrinking the objects. Region size must be a power of two between 1MB and 32MB; G1 auto-selects a default based on heap size, but a workload with consistently large allocations (image buffers, large batch payloads) benefits from setting it explicitly rather than relying on the auto-picked default.

Remembered sets are what let G1 collect a handful of young regions without scanning the entire heap for roots. A young-only collection needs to know every old-gen object that references a young object (otherwise a live young object could be missed as garbage), but scanning all of old gen on every minor collection would defeat the purpose of region-based, incremental collection entirely. Instead, each region keeps a remembered set (RSet) — a running list of which other regions point into it — updated incrementally via write barriers every time a reference field is written, using a coarse card table (the heap divided into small fixed-size "cards"; a write marks its card dirty) to keep the bookkeeping cheap. A collection then only needs to scan the RSets of the regions actually being collected, not the whole heap — this is the mechanism that makes G1's pause time roughly proportional to the collection set size, not total heap size, which is exactly what makes a soft MaxGCPauseMillis target achievable on multi-hundred-gigabyte heaps in the first place.

"To-space exhausted" precisely means G1 ran out of empty regions to evacuate live objects into, mid-collection. A G1 collection works by copying every live object out of the regions being reclaimed into fresh, empty regions (the "to-space") — it's a copying collector, not a mark-and-sweep-in-place one. If the heap's free regions run out during that copy (the live set turned out bigger than G1 predicted, often because of a burst of humongous allocations eating into the free-region pool), G1 can't safely stop partway through an evacuation, so it falls back to a full, single-threaded, stop-the-world garbage collection of the entire heap to recover — by far the most expensive pause type G1 can produce, and precisely why the whatIf case above (humongous allocations correlating with to-space exhaustion) is a real production failure mode, not just a log-noise curiosity.

Keywords they're listening for: