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

[William Kemper]

On Thu, 21 Sep 2023 21:47:19 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/shenandoahHeap.cpp line 947:
> 
>> 945:     control_thread()->handle_alloc_failure(req, false);
>> 946:     notify_gc_progress();
>> 947:     *gc_overhead_limit_was_exceeded = true;
> 
> I am confused. We have noted that we did more than `ShenandoahNoProgressThreshold` collections at this point. So we will fail the allocation request, set `gc_overhead_limit_was_exceeded`, and return `null` to the requester.
> 
> What happens at the caller, in response to this set of conditions?
> 
> Why then does it make sense to `notify_gc_progress()`, which clears the counter of `_gc_no_progress_count`? Where was the ostensible progress in this case?

Ultimately, the caller will have an OOME raised. The `_gc_no_progress_count` is cleared to allow subsequent mutator allocations to resume the slower block-and-retry loop in `ShenandoahHeap::allocate_memory`.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 292:
> 
>> 290:   ShenandoahSharedFlag   _concurrent_strong_root_in_progress;
>> 291: 
>> 292:   size_t _no_gc_progress_count;
> 
> Can we call this `_gc_no_progress_count` instead, so it's consistent with the corresponding `get_` method? The difference in naming is unnecessary at best and potentially confusing for maintenance in the long run, at worst.

Yes, I'll rename this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15852#discussion_r1333646726
PR Review Comment: https://git.openjdk.org/jdk/pull/15852#discussion_r1333646943