G1

the picture

you know how Parallel has to compact the whole old gen at once, so a big heap means a big pause? G1's answer: never collect the whole old gen. collect pieces of it.

think of a warehouse made of identical shipping containers. you can't empty the whole warehouse in one night. so every night you check which containers are mostly trash, move the few useful boxes out of them into one empty container, and send the rest off to be recycled. how many containers you deal with each night depends on how long the night is (the pause target). containers that are full of useful stuff, you just leave alone.

see why it's called garbage first? after marking, G1 knows exactly how much garbage each old region holds, and it always evacuates the worst ones first: the least copying for the most space back. and since everything gets evacuated (copied into a fresh region), the old gen gets compacted a few regions at a time. no fragmentation, no giant compaction pause.

one real cycle

here's a real G1 cycle, straight out of -Xlog:gc for the toy service from the last chapter (256 MB heap, 1 MB regions, jdk 25):

the lines it's made of, in the order they happen:

look at the remark line: 201M->135M. that 66 MB came back without copying a single object: whole regions that marking found to be 100% garbage are simply freed.

and here's G1 deciding what goes into one mixed GC (-Xlog:gc+ergo+cset=debug):

GC(8) Start adding marking candidates to collection set. Min 8 regions, max 26 regions,
      available 58 regions (11 groups), time remaining 195.70ms, optional threshold 39.14ms
GC(8) Finish adding marking candidates to collection set (Maximum number of regions reached).
GC(8) Pause Young (Mixed) (G1 Evacuation Pause) 198M->166M(256M) 1.467ms

58 old regions were worth collecting. G1 wants to get through them in at most 8 mixed GCs (-XX:G1MixedGCCountTarget=8), so at least 8 per pause. it will never take more than 10% of the heap's regions in one go (26 of 256). the predicted time was nowhere near the 200 ms goal, so the region cap is what stopped it. the actual pause: 1.5 ms.

remembered sets

collecting a handful of regions has the same problem as a young GC: objects outside the collection set might point in, and those pointers are roots. G1 can't scan the rest of the heap to find them, so every region keeps a remembered set: the list of cards (512-byte chunks) elsewhere in the heap that contain a pointer into it.

those sets are kept up to date by the post-write barrier. on a reference store, it checks whether the store crosses regions (and isn't null). if it does, it marks the card dirty and queues it, and background refinement threads move the card into the right remembered set. add the SATB pre-barrier from how GC works and that's G1's whole barrier story. it's also why G1 has a bit less throughput than Parallel: every reference store does a little extra work. java 26 cut that work down a lot (JEP 522): the app now just dirties a card in one table while refinement works on a second one, and the barrier went from around 50 instructions to 12 on x64.

the knobs worth knowing