JEP 333: ZGC: A Scalable Low-Latency Garbage Collector

AuthorsPer Liden, Stefan Karlsson
OwnerPer Liden
Created2018/02/13 09:58
Updated2018/05/07 09:53
Componenthotspot / gc
Discussionhotspot dash gc dash dev at openjdk dot java dot net
Reviewed byMikael Vidstedt, Stefan Karlsson
DependsJEP 312: Thread-Local Handshakes
JEP 304: Garbage Collector Interface


The Z Garbage Collector, also known as ZGC, is a scalable low-latency garbage collector.


We have strong ambitions to meet these goals for a large set of relevant workloads. At the same time, we want to acknowledge that we don't see these goals as hard requirements for every conceivable workload.


It is not a goal to provide working implementations for platforms other than Linux/x64. Support for additional platforms can be added later, if there is enough demand.


Garbage collection is one of Java's main strengths. However, when garbage collection pauses become too long they start to affect application response times negatively. By removing or drastically reducing the length of GC pauses, we'll make Java a more attractive platform for an even wider set of applications.

Furthermore, the amount of memory available in modern systems continues to grow. Users and application developers expect the JVM to be equipped to take full advantage of this memory in an efficient manner, and without long GC pause times.


At a glance, ZGC is a concurrent, single-generation, region-based, NUMA-aware, compacting collector. Stop-the-world phases are limited to root scanning, so GC pause times do not increase with the size of the heap or the live set.

A core design principle/choice in ZGC is the use of load barriers in combination with colored object pointers (i.e., colored oops). This is what enables ZGC to do concurrent operations, such as object relocation, while Java application threads are running. From a Java thread's perspective, the act of loading a reference field in a Java object is subject to a load barrier. In addition to an object address, a colored object pointer contains information used by the load barrier to determine if some action needs to be taken before allowing a Java thread to use the pointer. For example, the object might have been relocated, in which case the load barrier will detect the situation and take appropriate action.

Compared to alternative techniques, we believe the colored-pointers scheme offers some very attractive properties. In particular:



Most of our existing functional and stress tests are collector agnostic and can be reused as-is. Additional tests targeting properties and functions specific to ZGC will be added.