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

Kelvin Nilsen kdnilsen at openjdk.org
Wed Jun 19 22:18:23 UTC 2024


On Wed, 19 Jun 2024 18:22:07 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I'm of the "opinion" that consecutive Full GC failures means no intervening successful concurrent or degenerated collections.
>
> I'm proposing two changes:
> 1. Do not increment gc_no_progress in failed degens
> 2. Reset gc_no_progress to zero after successful concurrent gc
> 
> I will remove this comment, and I will test this change.  I believe this may allow me to backoff the extreme testing overrides of ShenandoahNoProgressThreshold.

If we don't reset gc_no_progress to zero after successful concurrent gc, it seems the use of ShenandoahNoProgressThreshold might be kind of "arbitrary".  For example, TestThreadFailure repeatedly drives the heap to exhaustion, and then it cleans up and does it again.  Each time it reaches exhaustion, we escalate to FullGC and throw OOM, which causes the mutator to release its memory.  Having released its memory, we'll run multiple successful concurrent GCs until we once again have exhausted memory, at which time we'll once again escalate to FullGC, which will be unproductive and we'll thrown OOM.

The sixth time though this loop (the sixth consecutive Full GC with many successful intervening concurrent GCs), we'll see that _gc_no_progress_count exceeds ShenandoahNoProgressThreshold and will throw OOM without even trying to do a Full GC.  I think this is not what we want.

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

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


More information about the shenandoah-dev mailing list