RFR: 8377180: Shenandoah: make escalation from degen to full more conservative
Kelvin Nilsen
kdnilsen at openjdk.org
Wed Feb 4 17:18:36 UTC 2026
This PR merges into Traditional Shenandoah an optimization that was applied to Generational Shenandoah in September 2025 and has proven itself effective in that context.
The change is to not immediately escalate Degenerated GC to Full GC following "bad progress" by Degen GC. The most common reason for bad degenerated progress is that most of the potential garbage was created following the start of the concurrent GC cycle which degenerated. This "floating" garbage cannot be reclaimed by the degenerated cycle because of the SATB protocol.
Pursuing at least one additional concurrent cycle, even if that subsequent concurrent GC, is usually a much better approach than forcing immediate escalation to Full GC. While escalation to full GC will resolve the out-of-memory condition, it imposes unnecessarily long stop-the-world pauses:
Existing behavior not to scale:
<--- Concurrent GC
experiencesallocation failure --> <-- Degen STW pause with bad progress --> <-- Full GC -->
[ STW pause is 100 ms degen + 3s full GC]
-------------
Commit messages:
- Delay escalation to full GC for traditional Shenandoah
Changes: https://git.openjdk.org/jdk/pull/29574/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29574&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8377180
Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/29574.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/29574/head:pull/29574
PR: https://git.openjdk.org/jdk/pull/29574
More information about the shenandoah-dev
mailing list