RFR: 8335126: Shenandoah: Improve OOM handling [v2]

[duke]

On Mon, 8 Jul 2024 17:09:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 1. Throw OOM after failed allocation request following a Full GC (rather
>>    than retrying as long as Full GC makes good progress because
>>    repeatedly retrying the allocation request creates brown-out behavior
>>    with no identified benefits on real-world workloads)
>> 
>> 2. Count a successful allocation following a blocking
>>    handle_allocation_failure() request to be good GC progress.
>>    Otherwise, we increment gc_no_progress_count in full GCs that
>>    have bad progress but successful allocations, and this causes
>>    unwanted failure to even try a full GC in a different thread after
>>    an out-of-memory condition might have been resolved in this thread.
>> 
>> 3. Count a completed concurrent GC cycle as good progress, regardless
>>    of how much memory it might have been able to reclaim.  The fact that
>>    concurrent GC succeeded without allocation failure and without
>>    degeneration is considered good progress.  Successful concurrent
>>    GCs between Full GCs will reset the gc_no_progress_count to zero.
>> 
>> 4. Do not count degenerated cycles as having no-progress.  If a
>>    degenerated cycle has no progress, it will upgrade to full GC.
>>    The upgraded full GC will evaluate its own progress.  We don't
>>    want to count this "same [upgraded] cycle" twice.
>> 
>> These changes have been tested over a variety of workloads and standard tests.  These changes have also been tested with the generational mode of Shenandoah.  It appears these changes provide more robust and consistent handling across a diversity of scenarios than the original implementation.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change TODO comment to reference JBS issue

@kdnilsen 
Your change (at version 24cd0fa655526ae7abc68630b07ba1eb5b094187) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19912#issuecomment-2214843005