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.
C4 uses a read barrier to support:
-
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.