ZGC joins the party: JEP 333 targeted to JDK 11
JDK 11 is shaping up to be a really great version. How do we know that? There are 13 JEPs targeted to JDK 11 so far. The latest “family” member is JEP 333. Although it’s still experimental, it’s certainly nice to see ZGC on the list. Let’s have a look at this JEP.
The countdown to JDK 11 has begun –sort of– and the list of JEPs is getting longer. Right now, there are 13 JEPs targeted to JDK 11, which is actually pretty great considering that JDK 10 had 12 features.
Anyway, back to the news. The latest JEP targeted to JDK 11 is experimental but we’re happy to see ZGC on the list, especially since its goal is to “make Java a more attractive platform for an even wider set of applications by removing or drastically reducing the length of GC pauses.”
Six months ago, we talked to Per Lidén, a Consulting Member of Technical Staff at Oracle about the plans for ZGC and the project’s goal. Here is a sneak peek; if you want to read the entire interview, you can find it here.
JAXenter: What is the ZGC Project and what is its aim?
Per Lidén: Garbage collection is one of Java’s main strengths. However, when garbage collection pauses get too long they start to affect the applications’ response time negatively. By removing or drastically reducing the length of GC pauses, we’re making Java a more attractive platform for an even wider set of applications.
The ZGC Project is an independent project under the larger OpenJDK community. It’s the home for the continued development of the ZGC code base, with the primary goal of creating a garbage collector that can handle medium- to very large heaps, while maintaining very low GC pause times.
A secondary goal is to make GC tuning dead simple. Most of the current GCs in OpenJDK have a large set of tuning options to allow it to work well on a wide set of workloads. However, using these tuning options often requires a deep understanding or how the GC works internally and what tradeoffs you face. Most developers just want the GC to work, and work well, without having to acquire this knowledge. In the ZGC project, we’ve been striving to create a GC where the need for tuning is reduced, without sacrificing performance.
JAXenter: What is the key principle of ZGC?
Per Lidén: From a high level, the key to achieving low latency, especially when using very large heaps, is to have the GC operate concurrently with the execution of the Java threads. If an operation must execute while the Java threads are stopped (i.e. in a Stop-The-World phase), it’s critical that the time to complete such operation does not increase with the heap- or live-set size.
In ZGC, we’ve worked hard to make sure that any Stop-The-World phase will either execute in constant time, or in the worst case, increase with the root-set size. The root-set size roughly correlates with the number of Java threads running.
When looking at specific techniques used in ZGC, we believe the use of colored pointers in combination with a low overhead load barrier is a very powerful, yet simple, foundation and a key enabler for concurrency.
JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
- GC pause times should not exceed 10ms
- Handle heaps ranging from relatively small (a few hundreds of megabytes) to very large (many terabytes) in size
- No more than 15% application throughput reduction compared to using G1
- Lay a foundation for future GC features and optimizations leveraging colored pointers and load barriers
- Initially supported platform: Linux/x64
The initial experimental version of ZGC will not have support for class unloading. The
ClassUnloadingWithConcurrentMark options will be disabled by default. Enabling them will have no effect.
Also, ZGC will initially not have support for JVMCI (i.e. Graal). An error message will be printed if the
EnableJVMCI option is enabled.
These limitations will be addressed at a later stage in this project.
These are the JEPs targeted to JDK 11, so far
181: Nest-Based Access Control
309: Dynamic Class-File Constants
315: Improve Aarch64 Intrinsics
318: Epsilon: A No-Op Garbage Collector
320: Remove the Java EE and CORBA Modules
321: HTTP Client (Standard)
323: Local-Variable Syntax for Lambda Parameters
324: Key Agreement with Curve25519 and Curve448
327: Unicode 10
328: Flight Recorder
329: ChaCha20 and Poly1305 Cryptographic Algorithms
330: Launch Single-File Source-Code Programs
333: ZGC: A Scalable Low-Latency Garbage Collector