RFR: 8316632: Shenandoah: Raise OOME when gc threshold is exceeded

[William Kemper]

On Thu, 21 Sep 2023 21:39:22 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Shenandoah will run back-to-back full GCs and _almost_ grind mutator progress to a halt before eventually exhausting memory. This change will have Shenandoah raise a gc threshold exceeded exception if the collector fails to make progress after `ShenandoahNoProgressThreshold` full GC cycles (default is 3).
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 124:
> 
>> 122:   ~ShenandoahControlThread();
>> 123: 
>> 124:   // Handle allocation failure from normal allocation.
> 
> Re "normal allocation" : what is not a normal (i.e. abnormal?) allocation?

I believe 'normal' here is a mutator allocation. I can update this comment.

> src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 125:
> 
>> 123: 
>> 124:   // Handle allocation failure from normal allocation.
>> 125:   // Optionally blocks while collector is handling the failure.
> 
> Who is allowed to call the non-blocking version? What is the semantics of block or don't block? Can the documentation be extended to elaborate on its use?

When a mutator allocation fails, it will block on this call and wait to be notified by the control thread to retry the allocation. The notification follows a degenerated or full GC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15852#discussion_r1333637391
PR Review Comment: https://git.openjdk.org/jdk/pull/15852#discussion_r1333638234