RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]

[Albert Mingkun Yang]

On Thu, 3 Jul 2025 00:52:56 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>>> I don't think throwing OOM, from gc's perspective, is an "error".
>> 
>> Nevermind; I just obey the statement in methods `MemAllocator::Allocation::check_out_of_memory` and `Universe::out_of_memory_error_java_heap`.
>
> Returning `null` outside of a safe point does have unexpected negative effects. e.g. `HeapDumpOnOutOfMemoryError` may not get good heap dump, as other threads can come in and run additional GCs, then the heap dump may contain confusingly little live data.
> 
> I wonder if you can improve this situtation.

Let me try to rephrase your concern to ensure that I understand you correctly -- after `_gc_overhead_counter >= GCOverheadLimitThreshold`, it's possible that another GC is triggered, which reclaims much free memory, and resets `_gc_overhead_counter` to zero. Then, `HeapDumpOnOutOfMemoryError` will not be able to get the intended heap snapshot.

Is my understanding correct?

(Seems that baseline resets the condition and can encounter the same problem as well.)


        if (limit_exceeded && softrefs_clear) {
          *gc_overhead_limit_was_exceeded = true;
          size_policy()->set_gc_overhead_limit_exceeded(false);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2188604729