Garbage Collection in Zing
One of the key reasons that many high-volume Java applications do not meet customer service level requirements is that application processing is often paused to perform garbage collection and reclaim available heap memory by the JVM. On traditional servers, these application pauses typically are several seconds to minutes long if the Java heap size is larger than the practical limit of 2 to 4 GB. The C4 Garbage Collector provides a solution for that problem.
About the C4 Garbage Collector
Azul’s Continuously Concurrent Compacting Collector (C4) is the only production-ready, generational pauseless garbage collector available in Java and a key component of Azul Platform Prime. C4 uses a 4-stage concurrent execution mechanism that eliminates almost all stop-the-world pauses. This lets your application continue executing while garbage collection is ongoing. Since 2010, Azul Zing Builds of OpenJDK (Zing) ships with a production implementation of the C4 collector mechanism, and many Fortune 500 companies run their code on C4 today.
Loaded Value Barrier
The Loaded Value Barrier (LVB) is part of the C4 Garbage Collector. It’s a type of read barrier inserted into the Java code (both compiled and interpreted) to facilitate efficient memory management and supports:
-
Concurrent Marking
-
Concurrent Relocation/Compaction
-
Concurrent Remapping
During the garbage collection phases, the LVB plays a crucial role by ensuring that any access to object references is properly managed, allowing the garbage collector to update or relocate objects without interrupting the execution of application threads. This approach enables the JVM to maintain high throughput and low latency, even with large heap sizes.
By utilizing the LVB, Zing’s C4 garbage collector achieves pauseless operation, providing consistent and predictable performance for Java applications. But in some cases, this can lead to a performance penalty.
In case your application has low allocation rates with a low GC frequency, you can enable Hybrid Mode using the option GPGCLvbCodeVersioningMode which instructs Falcon to generate two versions of the code: one with LVB and one without. When utilizing Hybrid Mode, your application uses LVBless Falcon compilations when there are no GCs active and switches to LVB Falcon code when the GC is active.
Hybrid Mode has two options, allMethods, which instructs Falcon to compile all methods twice, and sampling, which instructs Falcon to compile only hot methods. You can read more about these options on the Command Line Options page.
Default GC in Zing
-
Concurrent Compaction
-
Concurrent Remapping
-
Concurrent Incremental Update Tracing
C4 is the only Garbage Collector in Zing, replacing the other Garbage Collectors which are available in OpenJDK.
Configuring the C4 Garbage Collector
The default settings guarantee ideal behavior in most situations, but when needed, several command line options are available to fine-tune the behavior of the C4 Garbage Collector.
C4 White Paper
You can download the White Paper here that describes how C4:
-
Concurrently compacts the Java heap.
-
Allows the application to continue to execute while remapping of memory is performed.
-
Allows applications to completely separate heap size from response times.
-
Delivers predictable, consistent Java garbage collection behavior.