RFR: 8327000: GenShen: Integrate updated Shenandoah implementation of FreeSet into GenShen [v8]

[Kelvin Nilsen]

On Tue, 18 Jun 2024 01:51:02 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 93:
>> 
>>> 91:             ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder(
>>> 92:                     "-Xmx32m",
>>> 93:                     "-XX:+UnlockExperimentalVMOptions", "-XX:ShenandoahNoProgressThreshold=24",
>> 
>> See my previous comment about when `ShenandoahNoProgressThreshold` should increment earlier in code.
>
> Hmm, interesting, it looks like this does indeed increment only at a full gc, or at least that's the intent. Should check that this is also respected in the generational case. Vide:
> 
> 
>   product(uintx, ShenandoahNoProgressThreshold, 5, EXPERIMENTAL,            \
>           "After this number of consecutive Full GCs fail to make "         \
>           "progress, Shenandoah will raise out of memory errors. Note "     \
>           "that progress is determined by ShenandoahCriticalFreeThreshold") \
>                                                                             \

I'm testing now a configuration that honors the intent of this comment, to only increment gc_no_progress count if "consecutive Full GCs" fail to make progress.  This is not how it was implemented before, because our implementation has been also incrementing gc_no_progress count if degenerated fails to make progress, and we have not been resetting the count when we experience a productive concurrent GC.  My interpretation of the intent is that a concurrent GC happening between two unproductive Full GCs does not count as two "consecutive" unproductive full GCs.

If this change behaves well, we may be able to remove the ShenandoahNoProgressThreshold override on TestThreadFailure#generational.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/440#discussion_r1646679059