ZGC compacts the heap by moving live objects while application threads keep reading and writing them. Describe how it chooses what to move, how it prevents threads from working on a stale copy, and at what point the old memory can be handed back for reuse.

## Why concurrent relocation is the hard part Marking concurrently is comparatively easy: the object graph changes under you, and barriers plus a snapshot discipline handle it. **Moving** objects concurrently is much harder, because a thread can be holding a reference to an object that no longer lives where the reference says. Get this wrong and the application reads freed memory or two threads mutate two different copies of the same object. ZGC solves it with three ingredients: region-based heap layout, forwarding tables, and the load barrier. ## The heap layout ZGC's heap is divided into **ZPages** of a few sizes: *small* pages (2 MB, holding objects up to a few hundred KB), *medium* pages (32 MB, for larger objects), and *large* pages, each holding a single huge object. Large pages are never relocated — copying a multi-megabyte object to defragment is not worth it — so compaction concerns small and medium pages. Regions matter because compaction becomes *evacuation*: instead of sliding everything down as a classic compactor would, ZGC copies the survivors out of a chosen subset of pages into fresh pages, and frees the source pages whole. ## Choosing the relocation set Concurrent marking leaves per-page liveness statistics. Selecting the relocation set is then an optimization: pick the pages with the *lowest live-data ratio*, because each byte copied there frees the most bytes. A page that is 5 % live gives back 95 % of its space for the cost of copying 5 %. Fully empty pages are simply freed with no copying at all. This selection runs concurrently and ends with a short `Pause Relocate Start` that flips the remap color and fixes the roots so thread-held references point into the new world. ## Forwarding tables For every page in the relocation set, ZGC allocates an **off-heap forwarding table** — a small hash table keyed by the object's offset in the old page, whose value is the object's new address. Off-heap is deliberate: the forwarding data must survive the freeing of the old page, and it must not be reachable through a colored pointer. This is a design divergence worth noting: some concurrent compactors keep an indirection word in the object header, which means the old copy must stay alive until every reference has been updated. ZGC's state-in-the-pointer scheme means a mutator can tell from the *reference alone* that it must consult the collector, so the old copy is not needed as a signpost. ## The relocation protocol While the concurrent relocate phase runs: - GC workers walk the relocation set, copy each live object to a new page, and publish the mapping with a compare-and-set into the forwarding table. - Any application thread that loads a reference into a relocation-set page hits the load barrier's slow path. It looks in the forwarding table. If a mapping is present, it uses the new address. If not, it **copies the object itself**, then CASes the mapping in. If its CAS loses — a GC worker or another mutator got there first — it abandons its copy and uses the winner's address. Either way there is exactly one authoritative copy. - The barrier then self-heals: the corrected pointer is written back into the field it came from. Races are handled by that single CAS. There is never a window where two threads believe different addresses are current, because the CAS on the forwarding entry is the linearization point. ## When memory comes back As soon as a page's live objects have all been copied, the page is **freed and available for allocation** — even though references elsewhere in the heap still point into it. Those references are *bad-colored*, so anyone loading one is intercepted before dereferencing. This is what makes ZGC's memory reclamation prompt: free space returns during the relocate phase, not after a global fix-up. The forwarding tables must be retained until every reference into their pages has been repaired. That happens two ways: opportunistically, by load barriers as the application touches fields, and systematically, during the **next cycle's concurrent marking**, which traverses the reachable graph anyway and remaps every reference it walks. Once that traversal completes, the previous cycle's forwarding tables are released. That is why the phase is named "Concurrent Mark/Remap" — remapping is not a separate pass, it rides along on marking. ## Practical consequences - **No compaction pause.** Defragmentation, historically the most pause-prone GC activity, becomes concurrent work. - **Fragmentation is bounded** because compaction runs every cycle instead of being deferred to an emergency full collection. - **Mutators do some copying.** A request thread can pay for a few object copies, which appears as small latency jitter rather than as a pause. - **Headroom is required.** During relocation, both the old and the new copies exist and the application keeps allocating, so the collector needs free pages to copy into. Running the heap too close to full is what turns into allocation stalls.