Garbage collection in Java – the way which we 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) that is floating ariynd in the OpenJDK Java community calls for highly reducing latency by implementing region pinning to the G1 (Garbage-First) garbage collector. This means that the collection would not have to be disabled during Java Native Interface (JNI) critical regions. The goals of this plan include the following.
- 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.
[ Read More! Take a look at the Newest Features of Java 18. ]
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 way which we are using Garbage Collection, 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.
This 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 as of yet . The next version of standard Java, JDK (Java Development Kit) 18, which is due March 22, and its feature set has been frozen. Java Development Kit ( JDK) 19 should be following in September.