Java virtual machines (JVM) use built-in garbage collection (GC) technology to automatically manage memory usage within the Java heap. When an allocation failure occurs, a GC cycle is triggered to reclaim memory from objects that are no longer referenced. Typical GC implementations in modern JVMs require â€˜stop-the-worldâ€™ pauses, where application threads are suspended while the GC relocates live objects. Why? Because the JVM must ensure that all references to live objects, as visible to application threads, are accurate while the GC relocates live objects within the heap. However, for Java applications that have large heaps, and where response times are critical, â€˜stop-the-worldâ€™ pauses can result in unpredictable and inconsistent spikes in response times during a GC cycle.
To help mitigate this problem, the IBM J9 Virtual Machine (J9VM) incorporates a new execution mode from the Eclipse OpenJ9 JVM Project that aims to minimize the time spent in â€˜stop-the-worldâ€™ pauses by garbage collecting in parallel with running application threads. This mode works in conjunction with the new Guarded Storage Facility on the IBM z14TM (z14) Mainframe.
Figure (a) shows the traditional approach to garbage collection. Application threads are suspended, which allows the GC to safely move live objects and then update all the references. When a GC cycle completes, the application threads resume and are guaranteed to find only updated references.
Figure (b) shows the new approach, where stale objects are collected in parallel with running application threads. To achieve this, the GC must ensure that any reference to a live object from the application thread is valid before and after the GC has moved that object. During a GC cycle, the application thread validates all reference accesses from the heap and performs a reference relocation if a stale reference is detected. The Guarded Storage (GS) Facility provides hardware-based support to detect when potentially stale references are accessed. If an application thread loads a stale reference to an object that has been moved by the GC, the GS Facility detects this operation and triggers an interrupt to allow the reference to be relocated. As seen in Figure (b), compared to the traditional approach, the GS Facility allows application threads to execute concurrently with GC, thereby reducing â€˜stop-the-worldâ€™ pauses and improving overall response times.