Understanding ZGC: The Next‑Generation Low‑Latency Java Garbage Collector
ZGC, the Z Garbage Collector introduced in JDK 11, is a low‑latency, region‑based JVM garbage collector that uses colored pointers, load barriers, and multi‑mapping to achieve sub‑10 ms pause times across heap sizes up to several terabytes, with concurrent marking, relocation, and three brief STW phases.
ZGC (Z Garbage Collector) is a new JVM garbage collector launched with JDK 11, designed for ultra‑low pause times. Its primary goals are to keep stop‑the‑world (STW) pauses under 10 ms, make pause time independent of heap or live‑object size, and support heap sizes from 8 MB to several terabytes.
The collector is fully concurrent, region‑based, and employs several advanced techniques: dynamic region creation and destruction, colored pointers, load barriers, NUMA awareness, and multi‑mapping of memory.
Memory Layout : ZGC divides the heap into regions of three sizes—Small (2 MB for objects < 256 KB), Medium (32 MB for objects 256 KB–4 MB), and Large (multiples of 2 MB, each holding a single large object). Regions are created and destroyed dynamically.
Garbage‑Collection Mechanism : ZGC uses a concurrent mark‑copy algorithm. Apart from three brief STW phases (initial mark, final mark, and initial relocate), all marking, relocation, and reference updating happen concurrently, keeping pause times proportional only to the number of GC roots.
Colored Pointers : Instead of storing GC metadata in the object header, ZGC encodes it in the high bits of object references (the “colored pointer”), eliminating the need for extra memory accesses during marking.
Multi‑Mapping Address Space : Physical memory is mapped into three virtual views—Marked0, Marked1, and Remapped—using mmap. Each object has three virtual addresses that point to the same physical location, allowing the collector to switch views concurrently without stopping the application.
Read Barriers : ZGC inserts a small piece of code (read barrier) before every object reference read. This barrier determines whether the reference points to a live object and redirects it if necessary, enabling concurrent relocation.
The overall GC cycle proceeds through initialization (Remapped view), concurrent marking (switching to M0/M1 views), and concurrent relocation (returning to Remapped), with read barriers and colored pointers ensuring correctness throughout.
In summary, ZGC achieves near‑zero pause times by making almost the entire collection process concurrent, leveraging colored pointers, read barriers, and a multi‑mapped memory architecture, making it suitable for large‑scale, latency‑sensitive Java applications.
Mike Chen's Internet Architecture
Over ten years of BAT architecture experience, shared generously!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.