ZGC, and Choosing a Collector

Moving an object while the program runs#

So moving while running only works under one strict rule: once an object starts moving, no program thread may ever use its old address. The obvious way to enforce that is to lock every object access, so the GC and the program take turns. But that means a lock on every field read and write in the whole program, which would make it run many times slower.

Check every reference as it's loaded#

A program can only touch an object through a reference, and it gets that reference by loading it from somewhere, like a field, into a local variable. So if every reference is checked at the moment it's loaded, and fixed if it's out of date, the program can never hold an old address. That's what ZGC's load barrier does:

// you wrote:  Order o = list.first;
o = load list.first
if (o is not "good")                // fast path: one compare and a branch
    o = slow_path(o, &list.first)

Almost every time, the reference is good and the program carries on. When it isn't, the slow path:

1. Checks whether the object is in a region currently being emptied.
2. If it has already been copied, looks up its new address in that region's forwarding table (old address → new address).
3. If it hasn't been copied yet, the program thread copies it itself and installs the table entry. A GC thread may be copying the same object at that moment; the entry is installed atomically, so exactly one copy wins and both threads use it.
4. Writes the corrected reference back into the field it was loaded from, so the next load takes the fast path. This is called self-healing.
5. Returns the new address. The program never sees the old one.

Coloured pointers#

How can "is this reference good?" be one quick compare? A reference is a 64-bit number, and no heap needs all 64 bits for addresses. So ZGC uses a few spare bits in each stored reference to describe the reference itself. Those bits are its colour, hence coloured pointers.

At the start of each GC phase, ZGC changes which colour counts as good. That one change makes every reference in the heap out of date at once, without touching any of them. Each one is then checked and fixed the first time it's loaded, and it stays good after that.

What ZGC achieves, and what it costs#

ZGC marks and moves objects while the program runs. The pauses that remain are tiny, typically well under a millisecond, and they don't grow with heap size or live data; it supports heaps up to 16 TB. It also scans thread stacks concurrently, which is how it shrinks the pauses G1 keeps (Part 4). JDK 21 added a generational mode, with Part 3's young/old split; it became the default in JDK 23 and the only mode in JDK 24.

• Throughput: every reference load runs a check, and programs load references far more often than they store them. Generational ZGC adds store barriers too, which help with marking and track old-to-young references.
• CPU: GC threads work while your program runs, using CPU it could have had.
• Memory: ZGC can't use compressed 4-byte references, so the same objects take more space. And the program keeps allocating while ZGC collects. If free memory runs out first, the allocating thread waits. That's an allocation stall, and to whoever is waiting it feels exactly like a pause.

Shenandoah, a collector originally built by Red Hat and included in many OpenJDK builds, solves the same problem in a similar way: barriers on references plus forwarding addresses.

The four collectors, and choosing one#

Parallel just adds GC threads. Each row after that removes a stop-the-world phase and pays for it with more work while the program runs, in barriers and GC threads. So choose by which kind of pause you can't accept: Parallel when only total time matters, G1 as the default, ZGC when your longest pauses are unacceptable, especially on a large heap, and you can afford the extra CPU and memory.

And whichever you choose, the series' lessons hold. Short-lived objects are cheap; they die young and are never visited (Part 3). Large long-lived data is what costs, because every marking walks it and every compaction copies it (Parts 2, 4, 5). A bigger heap means fewer collections, not less work per collection, and with G1 and ZGC it also gives the collector room to finish before memory runs out.

If this comes up in an interview#