A change to Java’s G1 garbage collector would lower the memory and processing overhead and speed the execution of Java’s C2 optimizing JIT (just-in-time) compiler, benefiting cloud deployments, under a proposal in the Java community.
The OpenJDK proposal would simplify the implementation of G1’s barriers, which record information about application memory accesses, by shifting their expansion from early in the C2 JIT's compilation pipeline to later, the proposal states.
Underlying this proposal is the increasing popularity of cloud-based Java deployments, which has led to a stronger focus on reducing overall JVM overhead. Goals of the plan include reducing the execution of time of C2 when using the G1 collector, making G1 barriers comprehensible to HotSpot developers who lack a deep understanding of C2, and guaranteeing that C2 preserves invariants about the relative ordering of memory accesses, safepoints, and barriers. Another goal is preserving the quality of C2-generated code in terms of speed and size.
It is not a goal of the proposal to retain G1’s current early barrier expansion as a legacy mode, the proposal states, adding that the switch to late barrier expansion should be fully transparent, so a legacy mode is unnecessary. The proposal was created in mid-December 2023 and updated April 9, 2024.
In explaining the motivation for the plan, the proposal cites the increasing popularity of cloud deployments and the significant overhead incurred by JIT optimizing compilers such as C2. Preliminary experiments show that expanding G1 barriers early increases C2 overhead by about 10% to 20% depending on the application. Reducing this overhead is key to making the Java platform a better fit for the cloud, the proposal states.
Another major contributor to JVM overhead is the garbage collector (GC). Decoupling G1 barrier instrumentation from C2 internals would enable GC developers to further optimize and reduce the overhead of G1, by means of both algorithmic improvements and low-level micro-optimizations.
Finally, the proposal notes that the scope for C2 to optimize barrier code itself is limited and that code of similar quality could be generated if the barrier implementation details were hidden from C2 and expanded only at the end of the compilation pipeline. The authors therefore propose to expand G1 barriers as late as possible in C2’s compilation pipeline.