Can ZGC Deliver Sub‑10ms Pauses for Massive Java Heaps?

ZGC Goals

ZGC aims to provide a scalable, low‑latency garbage collector that reduces pause times to under 10 ms, even for terabyte‑scale heaps, at the cost of a modest throughput reduction.

Supports heap sizes up to several terabytes.

Maximum GC pause time ≤ 10 ms, independent of heap size.

Lays the foundation for future GC features.

Throughput may drop up to 15 % in worst cases.

Oracle also notes that pause time does not grow with heap size, so 10 ms pauses are achievable for 10‑100 GB or even TB‑scale heaps.

ZGC Overview

The collector introduces several novel concepts:

New GC architecture.

Single‑generation design (no generational spaces).

Region‑based memory management (ZPages of 2 MB, 32 MB, or N×2 MB).

Partial compaction similar to G1.

NUMA‑aware allocation.

Colored pointers storing GC metadata in the pointer itself.

Load barriers that update references on the fly.

Extensive tuning options.

Change log across JDK 11‑15.

New GC

ZGC differs from traditional HotSpot collectors (Parallel, CMS, G1) and is comparable to Azul’s C4. It runs on Linux 64‑bit in JDK 11, with macOS and Windows support added in JDK 14.

Benchmarks show ZGC pause times never exceed 10 ms, unlike Parallel and G1.

Garbage‑Collection Process

ZGC still has three stop‑the‑world (STW) phases and three concurrent phases:

Pause Mark Start – root scanning (very short, heap‑size independent).

Concurrent Mark/Remap – concurrent marking of live objects.

Pause Mark End – final short pause.

Concurrent Prepare for Relocate – selects regions to relocate.

Pause Relocate Start – moves only root references.

Concurrent Relocate – moves live objects to new regions.

Concurrent Relocate End – final cleanup.

Single Generation

ZGC does not use generational spaces, simplifying implementation at the expense of missing generational optimizations.

Region Based

Memory is divided into dynamically created “ZPages” of three possible sizes, offering flexibility compared with G1’s fixed‑size regions.

Partial Compaction

Only selected regions are compacted, reducing pause time compared with whole‑heap compaction.

NUMA‑aware

ZGC detects NUMA architectures and can allocate memory close to the executing CPU, improving performance on large servers.

Colored Pointers

GC metadata (finalizable, remapped, marked bits) is stored in the high bits of a 64‑bit object pointer, leaving 42 bits for the address (supporting up to 4 TB, extended to 16 TB in later JDKs).

Load Barriers

Every read of an object reference passes a load barrier that checks the pointer’s color; if the object has moved, the barrier updates the reference to the new address, eliminating the need for STW relocation.

ZGC Tuning

Enable ZGC with -XX:+UnlockExperimentalVMOptions -XX:+UseZGC. Common tuning flags include:

UseNUMA / -XX:-UseNUMA

UseLargePages

ConcGCThreads

ParallelGCThreads

ZUncommit and ZUncommitDelay

These parameters control NUMA usage, large‑page allocation, GC thread counts, and memory uncommit behavior.

Change Log

Key enhancements from JDK 11 to JDK 15 include improved NUMA awareness, class‑data sharing, heap on NVRAM, support for macOS and Windows, tiny‑heap support, and increased maximum heap size to 16 TB.

References

Further reading: OpenJDK ZGC wiki, various technical articles and presentations.