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