Oracle has announced its intention to make Z Garbage Collector (ZGC) open source. Per Liden, creator of ZGC at Oracle and member of Hotspot (and formerly JRockit) project, has proposed a new project in OpenJDK community to make ZGC open source.
ZGC has developed internally at Oracle with an aim to provide low-latency garbage collection for very large heaps. The main design goals of ZGC are:
- Handle multi-terabyte heaps
- Limit the GC pause time to no more than 10 milliseconds
- Throughput reduction of an application should be no more than 15% compared to G1
According to Liden, his team at Oracle has so far met or exceeded these goals on some well known industry benchmarks, and they have strong ambitions to meet these goals for a large set of relevant workloads; but these goals are not hard requirements for every scenario.
ZGC is a concurrent, single-generation garbage collector. Stop-The-World phases are limited to root scanning, which means GC pause times won't increase with the heap size.
Liden claims that the design and implementation of ZGC are already reasonably stable and mature. ZGC currently executes the following GC tasks concurrently:
- Marking
- Reference processing
- Relocation set selection
- Relocation/Compaction
According to Liden, a core design principle in ZGC is the use of load barriers with colored object pointers. This enables ZGC to perform concurrent operations, such as object relocation, while Java application threads are still running. A colored object pointer also contains information used by the load barrier to determine if some action needs to be taken before allowing Java thread to use the pointer.
Liden explains that the colored pointers approach offers some noteworthy properties such as:
- Ability to reclaim and reuse memory during the relocation/completion phase, before pointers pointing into the reclaimed/reused regions have been fixed. This approach helps in keeping the overall heap overhead down. This also eliminates the need to implement a separate mark-compact algorithm to handle full garbage collection.
- Relatively few and simple GC barriers, which helps in keeping the runtime overhead down. It also makes it easier to implement, optimize and maintain the GC barrier code in the interpreter and JIT compiler.
- Colored pointers are currently used to store marking and relocation related information, but the versatile nature of colored pointers scheme allows storing any type of information and lets the load barrier take any action it wants based on that information. This approach could be beneficial for future features.
According to the proposal on the OpenJDK forum, much of the remaining work involves addressing latency issues in non garbage collection subsystems in HotSpot, such as being able to concurrently unlink stale entries in the StringTable.
Liden wants to keep the change review process relaxed in the beginning, and make it stricter as the project gets close to integration. If the project is approved by the OpenJDK community, Liden would be the project lead and Oracle's HotSpot group would be the sponsoring group.
Votes were due by November 8, 2017, and the project is expected to be accepted, but no official announcement has been made yet.
