JEP draft: Make Shenandoah's generational mode the default
| Owner | William Kemper |
| Type | Feature |
| Scope | Implementation |
| Status | Draft |
| Component | hotspot / gc |
| Effort | XS |
| Duration | XS |
| Relates to | JEP 404: Generational Shenandoah (Experimental) |
| JEP 521: Generational Shenandoah | |
| Created | 2026/03/10 21:40 |
| Updated | 2026/03/10 21:41 |
| Issue | 8379682 |
Summary
Switch the default mode of the Shenandoah Garbage Collector to the generational mode. Deprecate the non-generational mode, with the intent to remove it in a future release.
Goals
- Signal the intent that future development will focus on Generational Shenandoah.
- Reduce the maintenance cost of supporting two different modes.
Non-Goals
- It is not a goal to remove non-generational Shenandoah at this time.
Motivation
Maintaining non-generational Shenandoah slows the development of new features. Generational Shenandoah collects young objects more frequently and old objects less frequently, resulting in lower concurrent overhead, better allocation throughput, and reduced memory footprint for most workloads.
Description
Make Generational Shenandoah the default mode by changing the default value of ShenandoahGCMode from satb to generational. Deprecate the satb mode.
After these changes the following behavior will be observed based on the provided command-line arguments:
-XX:+UseShenandoahGC- Generational Shenandoah is used.
-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational- Generational Shenandoah is used.
-XX:+UseShenandoahGC -XX:ShenandoahGCMode=satb- Non-generational Shenandoah is used.
- A warning that the
satbmode is deprecated for removal is issued.
Workloads that switch to Generational Shenandoah may experience differences in log output and in the data available from the serviceability and management APIs.
Testing
We will ensure that existing tests are unaffected by the deprecated option warning and that they pass in the same configurations as before this change.
Risks and Assumptions
Generational Shenandoah will perform differently than non-generational Shenandoah. The main risk this presents is that some workloads are non-generational by nature, and thus could see a slight performance degradation. We believe that this is a sufficiently small set of workloads that it does not justify the cost of maintaining two separate versions of Shenandoah over the long term.
Specific risks include:
- Users may be required to adjust configurations that are tuned for non-generational Shenandoah.
- The deprecation warning messages might cause issues for tools or scripts that parse JVM output.
- Workloads that are tightly coupled to JVM internals, GC logs, and the data available via management interfaces may require extra attention.