RFR: 8352765: G1CollectedHeap::expand_and_allocate() may fail to allocate even after heap expansion succeeds [v2]

[Man Cao]

On Thu, 27 Mar 2025 14:33:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this change to ensure that G1 provisions for at least one Eden region after a GC when computing the young length target.
>> 
>> The issue reported in the CR occurs at the end of a GC, after successfully expanding the heap, an allocation fails because `policy()->should_allocate_mutator_region()` returns false. This happens because the computation did not properly account for young regions already allocated as survivor regions, leading to an Eden region target of zero.
>> 
>> With this change, we factor in the young regions that have already been allocated as survivor regions and ensure that at least one region is targeted for Eden.
>> 
>> Testing: Tier 1-3
>>               Reproducer in the CR.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas Review

Thank you for the quick fix!

I just have a two questions, which probably does not need to be addressed in this PR.
1. Is it possible for `expand_and_allocate()` to run into the [`receiving_additional_eden = 0;`](https://github.com/openjdk/jdk/blob/2ea1557a0fdaf551d75365d1351bfbd73319dcfb/src/hotspot/share/gc/g1/g1Policy.cpp#L320) situation under the `if (allocated_young_length >= desired_young_length)` branch?
2. It feels like G1 should recalculate young list length parameters after a successful `expand()` or `shrink()`. Currently `G1Policy::record_new_heap_size()` only recalculates the min/max young lengths. Is it reasonable to run `calculate_young_desired_length()` and `calculate_young_target_length()` inside `G1Policy::record_new_heap_size()`?

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

Marked as reviewed by manc (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24257#pullrequestreview-2724441893