RFR: 8373714: Shenandoah: Register heuristic penalties following a degenerated GC [v2]

[William Kemper]

On Tue, 16 Dec 2025 23:30:58 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 321:
>> 
>>> 319:     op_degenerated_futile();
>>> 320:   } else {
>>> 321:     _generation->heuristics()->record_unsuccessful_degenerated();
>> 
>> Suggestion:
>> 
>>     _generation->heuristics()->record_successful_degenerated();
>> 
>> I think the confusion here is that we are conflating `progress` and `success`. The "progress" notion here is  about triggering a full GC or giving up entirely. The degenerated cycle is "successful" because it did not run a full GC. Maybe we should rename `record_successful_degenerated` to `record_degenerated` (or, perhaps even `apply_degenerated_penalty`). I was about to suggest we pull `record_success_degenerated` out of the logic entirely, but that would mean upgraded degen cycles would be penalized again when the full GC completes.
>
> May be let the heuristics (or the policy) track progress as well, and inform the actuator (i.e. op degenerated) whether it should upgrade to a full gc. It almost feels like heuristics and policy and actuator are leaking abstractions. It feels like heuristics keep track of the model parameters and learn from sensors, and the policy consults a specific heuristic to inform actuator (i.e. actions).
> 
> By that model, you'd have the actuator sending the sensor information to the heuristics and asking the policy (or the heuristics, if you conflate heuristics and policy) to decide which step to take next. It would seem that evaluation of the notion of progress then moves to the policy too.

@kdnilsen , what do you think about having a single method called `record_degenerated`. It's a matter of fact without conflating progress and success. I don't like having duplicated code between `record_success_degenerated` and `record_unsuccessful_degenerated`. I understand what @ysramakrishna is saying, and I agree, but I think a change like that is beyond the scope of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28834#discussion_r2666242735