Java proposal would lower GC latency

Java garbage collection – the reallocation of memory through deletion of unused objects – would be improved through a proposal being considered by the developers of standard Java.

A JDK Enhancement Proposal (JEP) being floated in the OpenJDK Java community calls for reducing latency by implementing region pinning to the G1 (Garbage-First) garbage collector, so collection would not have to be disabled during Java Native Interface (JNI) critical regions. Goals of this plan include:

• No stalling of threads due to JNI critical regions.
• No additional latency to start garbage collection due to JNI critical regions.
• Minimal regressions in GC pauses times when no JNI critical regions are active.
• No regressions in GC pause times when no critical JNI regions are active.

In explaining the motivation for this plan, proponents said that for interoperability with unmanaged programming languages such as C and C++, JNI defines functions to get and then release direct pointers to Java objects. These functions must be in pairs: first, get a pointer to an object; then, after using the object, release the pointer.

Code in such function pairs is considered to run in a critical region, and the Java object in use is a critical object. When a Java thread is in a critical region, the JVM must not move the associated critical object during garbage collection. It can do this by pinning such objects to their locations, essentially locking them in place as the GC moves other objects. Or, the JVM might disable GC when a thread is in a critical region.

The default GC, G1, takes the latter approach, disabling collection during every critical region. This significantly impacts latency. Under the proposal being considered, Java threads would never wait for a G1 GC operation to complete. Goals of the proposal would be met by extending G1 to pin arbitrary regions during major and minor collection operations.

The proposal presumes there will be no changes to expected usage of JNI critical regions; they will continue to be used sparingly and be short in duration. There is a risk of heap exhaustion when an application pins many regions at the same time. There currently is no solution for this, but the fact that the Shenandoah GC pins memory regions during JNI critical regions and does not have this problem suggests it would not be a problem for G1.

The proposal currently does not cite a version of Java in which this capability might be introduced. The next version of standard Java, JDK (Java Development Kit) 18, is due March 22, and its feature set has been frozen. JDK 19 would normally follow in September.