How ZGC Achieves Sub‑10 ms Pauses and Scalable Memory Management

What Is ZGC?

ZGC (Z Garbage Collector) is a low‑latency garbage collector that outperforms G1. It first appeared experimentally in JDK 11, became production‑ready in JDK 15, and can be enabled with -XX:+UseZGC.

Key Characteristics

Pause times never exceed 10 ms.

Since JDK 16, pauses are typically under 1 ms and have O(1) time complexity, independent of heap size.

After JDK 16, GC pause time shrank to under 1 ms and does not grow with heap size.

ZGC supports heap sizes from 8 MB up to 16 TB while affecting application throughput by less than 15 % compared with G1.

1. Memory Multi‑Mapping

ZGC uses mmap to map the same physical memory into three virtual address spaces: Marked0 , Marked1 and Remapped . When an object is allocated, ZGC reserves a virtual address in each of the three views, all pointing to the same physical location. Only one view is active at a time, and ZGC switches between them to perform concurrent collection.

2. Colored Pointers

2.1 Three‑Color Marking Review

G1 uses the classic three‑color marking algorithm:

White – object not yet visited.

Gray – object visited, but its children not fully processed.

Black – object and all reachable children visited.

2.2 Storing GC State in Pointers

Traditional collectors store GC metadata in the object header’s Mark Word. ZGC instead encodes a few bits directly in the object pointer (a “colored pointer”). In a 64‑bit JVM, the high 16 bits are unused for addressing; the remaining 48 bits hold the address, and the top 4 bits of those are used for flags indicating:

Marked0 / Marked1 – current view.

Remapped – object moved to the remapped view.

Finalizable – object requires finalization.

This allows the JVM to read an object’s GC state without dereferencing the object itself, dramatically reducing overhead.

3. Memory Layout

Like G1, ZGC divides the heap into regions, but it does not distinguish young and old generations. ZGC’s region types are:

Small Region – 2 MB, for objects < 256 KB.

Medium Region – 32 MB, for objects between 256 KB and 4 MB.

Large Region – N × 2 MB (minimum 4 MB), each holding a single large object and never subject to remapping.

4. Read Barrier

A read barrier is injected before any heap reference is read. It runs only when a reference is fetched from the heap, enabling the collector to update view information on‑the‑fly.

Object o = obj.FieldA
Object p = o // not a heap read
o.doSomething() // not a heap read
int i = obj.FieldB // primitive, no barrier

The barrier checks the object’s current view and may switch it to Marked0 if needed.

Read barriers can add up to about 4 % runtime overhead, but they greatly improve GC concurrency and reduce stop‑the‑world pauses.

5. GC Process

ZGC’s collection consists of three main phases—marking, relocation, and compaction—each split into sub‑steps.

5.1 Initial Mark

All objects reachable directly from GC roots are marked in a short STW pause. The pause duration is proportional to the number of roots, not to heap size.

5.2 Concurrent Mark

If a GC thread sees an object in the Remapped view, it switches the view to Marked0 and marks it.

New objects created by application threads are placed directly into Marked0 .

Application threads reading a Remapped object also trigger a view switch to Marked0 via the read barrier.

After concurrent marking, objects still in Marked0 are considered live; those remaining in Remapped are dead.

5.3 Re‑Mark

Any objects whose reference graph changed during concurrent marking are re‑marked in a brief STW pause.

5.4 Initial Relocation

Live objects are copied to new memory locations while the old space is reclaimed. This step also requires a short STW pause proportional to the number of GC roots.

5.5 Concurrent Relocation

If a GC thread encounters an object in Marked0 , it copies the object and changes its view to Remapped .

Objects already in Remapped are skipped.

Application‑created objects start in Remapped and are later moved if they become live.

5.6 Compaction (Relocation)

After copying, all pointers that still reference old addresses are updated to point to the new locations.

6. Collection Algorithm

ZGC uses a mark‑compact algorithm: live objects are moved to one side of the heap, and the remaining space is reclaimed.

6.1 Pre‑JDK 16 Approach

Earlier versions reserved a separate “reserve” area that could only be used by the collector during relocation. This simplified parallel collection but wasted memory and could cause OOM if the reserve was insufficient.

6.2 JDK 16 Improvements

JDK 16 introduced in‑place relocation, eliminating the need for a dedicated reserve region. ZGC now prefers in‑place moves when free regions are available, falling back to a reserve‑style approach only when necessary. This reduces memory waste but requires careful coordination among GC threads to avoid overwriting objects that have not yet been moved.

7. Summary

Memory multi‑mapping and colored pointers give ZGC a substantial concurrency advantage, reducing stop‑the‑world pauses to only three short phases (initial mark, initial relocation, and a tiny re‑mark). Pause time scales with the number of GC roots, not with heap size, but the lack of generational collection can lead to “floating” garbage that is reclaimed only in later cycles.