How Generational ZGC works
See how modern Generational ZGC uses young and old regions, colored pointers, barriers, remembered sets, marking, and relocation.
The whole story in 6 lines
Follow young and old regions, colored pointers, store and load barriers, remembered sets, marking, and relocation through one modern ZGC...
- Page-based layout enables per-page evacuation and concurrent compaction without whole-heap STW.
- Colored pointers let the GC communicate state through every reference without touching the object header.
- Act-once store barriers record precise old-field addresses in double-buffered remembered sets for young collections.
- The optimized load barrier turns a colored field value into a colorless address and repairs it only when relocation made that address stale.
- SATB store barriers preserve overwritten references so concurrent marking can finish its starting snapshot.
- Relocation selects sparse pages, moves live objects to new pages, and lets the barrier fix references lazily.
Setup
Welcome. Since JDK 24, selecting ZGC means using the generational collector. The older non-generational mode has been removed. This explainer follows the current design and keeps its concurrent boundaries visible.
A ZPage is a contiguous chunk of memory that holds Java objects. ZGC divides the entire heap into these pages instead of using one big slab. Think of them like numbered containers in a warehouse.
A colored pointer is a 64-bit object reference that carries collection metadata with the address. Generational ZGC stores colored references in object fields, while registers and stack slots use dereferenceable colorless addresses.
A load barrier removes pointer metadata and repairs a stale address when application code reads an object field. A store barrier colors new references, supports marking, and records fields that may point from old objects to young ones.
A forwarding table records where a relocated object moved, while a remembered set records precise old-generation field locations that may point into the young generation. These structures let independent collections remain correct.
Over the next six stages, we will trace heap regions, colored references, store barriers and remembered sets, the load barrier, concurrent marking, and relocation. Let us start with how memory is organized.
Heap Pages
The JVM starts with a heap divided into ZPages. There are three sizes: small pages are 2 MB, medium pages are 32 MB, and large pages are multiples of 2 MB reserved for huge objects. This per-page organization is what makes concurrent relocation possible.
Small pages hold objects up to 256 KB. They are the most common page type and the majority of your allocations land here. Watch the objects fill the page from left to right.
When an object exceeds 256 KB but stays under 4 MB, the allocator places it in a medium page. Medium pages are 32 MB and give larger objects room to breathe without wasting a whole large page.
Objects larger than 4 MB get their own large page. A large page is sized exactly to fit one object, always a multiple of 2 MB. Only one object ever lives in a large page.
When ZGC needs to compact the heap, it evacuates entire pages by relocating all live objects out, then reclaims the page. This page-at-a-time approach means the collector never needs to pause to compact the whole heap at once. That is the first piece of the sub-millisecond puzzle.
Colored Pointers
Generational ZGC tracks reference state inside each 64-bit heap-field value. The value combines an encoded object address with metadata used by the collector's barriers.
The current colored-pointer layout places metadata in low-order bits and an encoded object address in the high-order bits. That layout lets optimized machine code test and strip metadata efficiently.
Distinct metadata tracks marking and relocation for the young and old generations. Store barriers use those states for marking and remembered-set work, while load barriers check whether an address needs relocation repair.
The stage has reached the decision that determines its next state. What does a modern ZGC load barrier repair?
The payoff is a division of labor. A store barrier adds metadata as a reference enters a heap field, while a load barrier removes metadata before the application uses the address.
Colored references therefore stay inside heap fields and barrier code. Registers and the hardware stack receive colorless pointers, so ordinary machine instructions never dereference metadata bits. Next, we will see why stores need precise remembered sets.
Store Barriers + Remembered Sets
The heap is split into young and old generations that can be collected independently. A young collection normally visits young objects, but an old object may hold the only reference that keeps a young object alive.
Suppose the application stores a reference to young object Y into field f of old object O. That write crosses the generational boundary, so the field must become an additional root for the next young collection.
The store barrier checks the pointer state before overwriting f. On the first relevant write in this collection interval, its slow path records the precise address of f and colors the new reference.
The recorded field appears in the active remembered-set bitmap. A second bitmap is reserved for the collector, so application threads can continue recording without contending with a concurrent scan.
At the next young collection, ZGC atomically swaps the two bitmaps. The collector scans the stable copy while barriers populate the other one. This precise, double-buffered handoff belongs to the modern generational architecture, which no longer uses legacy virtual-address aliasing.
Load Barrier
★ If you remember one thing · A stale reference can still reach the relocated object because the load barrier repairs the address at use time.
We now know that heap fields contain colored references, while the CPU needs a colorless address. The JIT inserts a load barrier wherever application code reads an object reference from a field.
The stage has reached the decision that determines its next state. Which case forces the load barrier to consult relocation information?
If relocation made the address stale, the slow path follows forwarding information to the object's current location. It then heals the field so later application reads normally remain on the fast path.
Switch the Scenario control through every choice. Compare the downstream outcome while the earlier input and system boundary remain fixed.
Because the barrier heals the referring field, repeated reads can use the fast path until another collection changes the relevant state. Store barriers handle marking and remembered sets. Load barriers stay focused on metadata removal and relocation repair, keeping the frequent read path deliberately narrow.
Concurrent Marking
We have regions, colored references, remembered sets, and both barriers. Now let us see them cooperate during a marking cycle, where the collector must find every object reachable from the starting snapshot.
The cycle begins from a snapshot of GC roots such as thread stacks, static fields, and JNI handles. Young marking also treats remembered old-to-young fields as roots of the young object graph.
After root capture, application threads resume while GC workers traverse reachable objects concurrently. Young and old generations have distinct marking metadata so one generation can be collected without conflating the other's state.
Application threads can overwrite references while workers traverse the graph. The SATB store barrier reports the previous field value on its first relevant write, preserving objects that were reachable when marking began.
The collector drains the remaining barrier work and completes marking with a stable liveness result. That result separates live objects from garbage before relocation begins, so space can be reclaimed region by region.
The result is a liveness map built mostly concurrently while store barriers protected the starting snapshot. Next, ZGC uses complete liveness information to choose regions and relocate live objects without reserving a second young generation.
Concurrent Relocation
Marking told ZGC which objects are alive. Now it uses that information to compact the heap. The first step is selecting the relocation set: the pages with the lowest liveness ratios. Sparse pages waste the most memory, so they are relocated first.
For each page in the relocation set, ZGC allocates a forwarding table. This table will map every old object address to its new location. Watch the forwarding table appear next to the source page.
GC worker threads begin moving live objects from the source page to a fresh target page. Each moved object gets an entry in the forwarding table. The application keeps running during this entire process.
When an application thread loads a reference to an object that was relocated, the load barrier kicks in. It detects the stale color, looks up the forwarding table, finds the new address, and updates the pointer in place. This is the self-healing we saw in Stage 4, now applied at scale across the entire relocation set.
After all live objects are evacuated, the source page is reclaimed. Its forwarding table stays alive until the next mark cycle remaps all remaining stale references. Then the forwarding table is freed too.
That completes the relocation path. Regions are selected, objects move concurrently, stale references heal through load barriers, and evacuated space becomes reusable. Most of the work runs alongside the application, keeping stop-the-world work deliberately small.
Recap
We started with Heap Pages. ZGC divides the heap into small, medium, and large pages. This per-page organization means the collector can evacuate one page at a time instead of stopping the world to compact everything.
Then we learned about Colored Pointers. Heap fields carry address and collection metadata together, while barrier code translates those values into colorless addresses before registers and ordinary machine instructions use them.
Store Barriers make generations work together. They preserve overwritten values for SATB marking and record precise old-generation field addresses in double-buffered remembered sets for young collections.
The Load Barrier removes metadata and checks whether relocation made an address stale. When repair is necessary, it follows forwarding information and heals the field so subsequent reads can return to the fast path.
Concurrent Marking traces the live object graph from a starting snapshot. Store barriers preserve overwritten references during that traversal, and remembered old-to-young fields join the roots of a young collection.
Concurrent Relocation selects sparse pages, moves live objects to fresh pages, and records the new addresses in forwarding tables. The load barrier heals stale pointers on the fly. Empty pages are reclaimed without any pause.
Together these mechanisms form the current Generational ZGC design. Colored references carry state, store barriers protect marking and generation boundaries, load barriers repair relocated addresses, and region-based relocation reuses evacuated space while applications keep running.
The whole story in 6 lines
Follow young and old regions, colored pointers, store and load barriers, remembered sets, marking, and relocation through one modern ZGC...
- Page-based layout enables per-page evacuation and concurrent compaction without whole-heap STW.
- Colored pointers let the GC communicate state through every reference without touching the object header.
- Act-once store barriers record precise old-field addresses in double-buffered remembered sets for young collections.
- The optimized load barrier turns a colored field value into a colorless address and repairs it only when relocation made that address stale.
- SATB store barriers preserve overwritten references so concurrent marking can finish its starting snapshot.
- Relocation selects sparse pages, moves live objects to new pages, and lets the barrier fix references lazily.