How Shenandoah and ZGC Achieve Sub‑10ms Pauses in Modern Java
This article compares the Shenandoah and ZGC garbage collectors introduced in OpenJDK, explaining their design goals, key differences from G1, core mechanisms such as connection matrices and forwarding or colored pointers, and detailing each collector’s concurrent phases to achieve pause times under 10 ms regardless of heap size.
Shenandoah
Shenandoah (named after a Native American word) first appeared in OpenJDK 12, developed by Red Hat to address long GC pauses when handling large heaps. Its design goal is to keep pause times below 10 ms, independent of heap size, making it more aggressive than G1, which targets hundreds of milliseconds.
"Successor of G1"
Shenandoah shares much code with G1 but differs in three main aspects:
G1 performs stop‑the‑world (STW) pauses that account for over 80 % of total pause time, whereas Shenandoah implements fully concurrent collection.
Shenandoah does not separate young and old generations.
Shenandoah replaces G1’s card table with a connection matrix.
Connection Matrix
Instead of a per‑object card table, Shenandoah uses a two‑dimensional matrix that marks a whole Region when any object in Region A points to an object in Region B. This reduces memory overhead and scanning cost, though it scans larger regions.
Forwarding Pointer
To enable concurrent evacuation, Shenandoah copies live objects to empty Regions while the application threads run, leaving both old and new copies in the heap. A forwarding pointer added to the object header directs reads to the new copy. Compared with the earlier memory‑protection‑trap approach, forwarding pointers reduce the overhead of kernel‑mode transitions, though they introduce thread‑safety and barrier‑performance challenges. Shenandoah mitigates these by using CAS for pointer updates and, starting with JDK 13, applying read barriers only to reference accesses.
Shenandoah Execution Steps
Initial Mark (STW) – mark objects directly reachable from GC roots.
Concurrent Marking – traverse the object graph and mark all reachable objects.
Final Mark (STW) – finish marking and select Regions with the highest reclaim value.
Concurrent Cleanup – reclaim Regions that contain no live objects (Immediate Garbage Regions).
Concurrent Evacuation – copy live objects from selected Regions to free Regions, using forwarding pointers to resolve old‑to‑new references.
Initial Update References (STW) – set a barrier to ensure all concurrent work is finished.
Concurrent Update References – walk the heap linearly and update references to the new copies.
Final Update References (STW) – fix references in GC roots.
Concurrent Cleanup – reclaim Regions that have become empty after evacuation.
ZGC
ZGC, developed by Oracle and introduced in JDK 11 (production‑ready in JDK 15), targets terabyte‑scale heaps with pause times under 10 ms and a throughput impact below 15 %.
Memory Layout
ZGC divides the heap into Regions (called Pages) of three sizes:
Small Region – fixed 2 MiB, stores objects < 256 KiB.
Medium Region – fixed 32 MiB, stores objects 256 KiB – 4 MiB.
Large Region – multiples of 2 MiB, each holds a single object ≥ 4 MiB.
Relocation Set
During marking, ZGC scans all Regions; those containing live objects that need to be moved are placed into the Relocation Set, which determines which Regions will be reclaimed.
Colored Pointers
ZGC uses colored pointers instead of forwarding pointers. The three‑color marking is stored directly in the pointer’s high bits: two bits for Mark 0/Mark 1, one bit for Remapped, and one for Finalizable. On 64‑bit Linux, 4 of the high 18 unused bits are repurposed, leaving 42 bits for a 4 TiB address space.
6 4 4 4 4 4 0
3 7 6 5 2 1 0
+-------------------+-+----+-----------------------------------------------+
|00000000 00000000 0|0|1111|11 11111111 11111111 11111111 11111111 11111111|
+-------------------+-+----+-----------------------------------------------+
| | | |
| | | * 41-0 Object Offset (42‑bits, 4TB address space)
| | |
| | * 45-42 Metadata Bits (4‑bits) 0001 = Marked0
| | 0010 = Marked1
| | 0100 = Remapped
| | 1000 = Finalizable
| * 46-46 Unused (1‑bit, always zero)
|* 63-47 Fixed (17‑bits, always zero)Two mark bits (M0 and M1) allow overlapping GC cycles: while one cycle finishes marking, the next can start using the other bits.
Advantages of Colored Pointers
Self‑healing: when a Page is reclaimed, references are instantly redirected without waiting for a full update.
No write barriers are needed because object headers are untouched and there is no generational collection.
The remaining unused bits provide ample room for future extensions.
Other Features
ZGC does not use generational collection, relying instead on full‑heap scanning. It employs read barriers for self‑healing and leverages NUMA‑aware allocation to reduce memory‑access contention. Unlike earlier collectors, ZGC avoids write barriers entirely.
Summary
Modern garbage collectors push concurrency to achieve ultra‑low pause times. Shenandoah builds on G1 with aggressive optimizations such as connection matrices and refined forwarding pointers, while ZGC adopts colored pointers, NUMA‑aware allocation, and read‑barrier‑only designs. Both aim to let Java developers focus on application logic while the GC handles memory management efficiently.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
JD Cloud Developers
JD Cloud Developers (Developer of JD Technology) is a JD Technology Group platform offering technical sharing and communication for AI, cloud computing, IoT and related developers. It publishes JD product technical information, industry content, and tech event news. Embrace technology and partner with developers to envision the future.
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.
