Article originally posted on InfoQ. Visit InfoQ

JEP 404, Generational Shenandoah (Experimental), has been promoted from Proposed to Target to Targeted for JDK 21. This JEP proposes to “enhance the Shenandoah garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resilience, and memory utilization.” Compared to other garbage collectors, such as G1, CMS, and Parallel, Shenandoah currently requires additional heap headroom and has a more difficult time recovering space occupied by unreachable objects.

The Shenandoah garbage collector, utilized in Java applications for its low pause times and latency sensitivity, has been upgraded to include experimental generational collection capabilities. The enhancement is aimed at improving sustainable throughput, load-spike resilience, and memory utilization. The Shenandoah GC can be activated by using the following JVM command line options:

-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational

This will shift Shenandoah into its generational mode. Detailed guidance for configuring and tuning the JVM for optimal operation of applications running with Shenandoah GC in generational mode is available on the project wiki.

The Shenandoah GC is designed to minimize the average GC cost, and the new mode adopts the generational hypothesis that most objects die young. Hence, GC efforts should focus more on dealing with young, short-lived objects. The implementation, currently in its experimental phase, is expected to offer dynamic adaptability for varied workloads.

The enhancement divides the Java heap into two generations: the young and the old. Each generation is composed of a subset of the Shenandoah heap’s regions, with a specific size determined by its occupied regions plus a quota of free regions.

The enhancement doesn’t aim to replace non-generational Shenandoah or improve performance for every possible workload. It isn’t intended to maximize mutator throughput or improve CPU and power usage compared to traditional stop-the-world GCs. Instead, it focuses on reducing the sustained memory footprint, CPU and power usage while increasing throughput and resilience during allocation spikes.

Testing for generational Shenandoah will involve benchmarking against the non-generational version using SPECjbb2015, HyperAlloc, Extremem and Dacapo. Operational envelopes for HyperAlloc, Extremem, and similar workloads will be compared to non-generational Shenandoah, with successful runs aiming to reduce or eliminate the number of allocation stalls and the need for full or degenerated collections.

This enhancement to Shenandoah is seen as a major step forward in garbage collection for Java applications. Its unique Load Reference Barrier (LRB) supports both 32-bit builds and compressed object pointers in 64-bit builds, which the majority of Java heaps are able to take advantage of, making it an efficient and valuable feature.

While the enhancement comes with the risk of increased pause times and mutator overhead due to remembered-set operations, the team is actively refining the algorithms to control collection-phase scheduling, young-generation sizing, tenuring age, and other auto-tuning mechanisms.

The Shenandoah team has clearly stated that this enhancement is in an experimental phase and may require manual tuning for optimal performance. As the system continues to be refined and improved while conducting all development operations in the openjdk/shenandoah repository on the master branch, it is expected to bring considerable performance enhancements to Java applications running with Shenandoah GC. This update places Shenandoah at the forefront of Java garbage collection, showcasing its potential to revolutionize the process.