RFR: 8354452: Shenandoah: Enforce range checks on parameters controlling heuristic sleep times

[William Kemper]

On Fri, 11 Apr 2025 20:55:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Without enforcing limits on `ShenandoahControlIntervalMin` and `ShenandoahControlIntervalMax`, the user may supply values that cause assertions to fail.
>> 
>> This assertion failure has been observed in Genshen's regulator thread:
>> 
>> #0 0x000028e8062d021a in ShenandoahRegulatorThread::regulator_sleep (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:125
>> #1 0x000028e8062d0027 in ShenandoahRegulatorThread::regulate_young_and_old_cycles (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:95
>> #2 0x000028e8062cfd06 in ShenandoahRegulatorThread::run_service (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:51
>> 
>> But it could just as easily happen in other modes to the `ShenandoahControlThread` instance.
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 1:
> 
>> 1: /*
> 
> Change looks fine, but I wonder about using a `naked_sleep()` and allowing longer durations without triggering asserts in those cases? Not sure where this could be used and whether 1-second is the maximum we might like for these numbers regardless.

1 second is enforced by `naked_sleep` itself, so raising it would impact all callers. Not using `naked_sleep` would be possible here, but the default maximum sleep time is 10ms. Even 1 second (well, 999ms) would make the heuristics dangerously slow to respond.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24602#discussion_r2040294574