RFR: 8368152: Shenandoah: Incorrect behavior at end of degenerated cycle [v3]

[William Kemper]

On Tue, 23 Sep 2025 21:33:53 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp line 117:
> 
>> 115:   // Genshen will only upgrade to a full gc after the configured number of futile degenerated cycles.
>> 116:   bool should_upgrade_degenerated_gc() const {
>> 117:     return _consecutive_degenerated_gcs_without_progress >= CONSECUTIVE_BAD_DEGEN_PROGRESS_THRESHOLD;
> 
> assert that heap is generational? See previous comment above at line 68.

I renamed the method, but I don't want to put an assert on the mode here because it would make the unit test much harder to run.

> src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 323:
> 
>> 321:   // Shenandoah to avoid introducing "surprising new behavior."  It also makes less sense with non-generational
>> 322:   // Shenandoah to replace a full GC with a degenerated GC, because both have similar pause times in non-generational
>> 323:   // mode.
> 
> May be, based on the first paragraph above, you want to say more simply (replacing the entire second paragraph):
> 
> On the other hand, in non-generational mode,
> to both preserve legacy behavior, and because the
> difference between a degenerated gc and full gc is smaller,
> we immediately escalate to
> a full gc following the first degenerated cycle that doesn't make progress.
> 
> 
> I'd also move this comment out from here and to the constant that was defined for the number of consecutive degens before escalating to full in generational mode.

I moved the whole explanation into `shCollectorPolicy`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373573529
PR Review Comment: https://git.openjdk.org/jdk/pull/27456#discussion_r2373574294