RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics [v6]

[Thomas Schatzl]

On Tue, 1 Apr 2025 20:54:36 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> I have implemented SoftMaxHeapSize for G1 as attached. It is completely reworked compared to [previous PR](https://github.com/openjdk/jdk/pull/20783), and excludes code for `CurrentMaxHeapSize`. I believe I have addressed all direct concerns from [previous email thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050214.html), such as:
>> 
>> - does not respect `MinHeapSize`;
>> - being too "blunt" and does not respect other G1 heuristics and flags for resizing, such as `MinHeapFreeRatio`, `MaxHeapFreeRatio`;
>> - does not affect heuristcs to trigger a concurrent cycle;
>> 
>> [This recent thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-March/051619.html) also has some context.
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments and try fixing test failure on macos-aarch64

There also seems to be a concurrency issue with reading the `SoftMaxHeapSize` variable: Since the flag is manageable, at least outside of safepoints (afaict `jcmd` is blocked by safepoints, but I'll ask), the variable can be written to it at any time.

So e.g. the assignment of `G1IHOPControl::get_conc_mark_start_threshold` to `marking_initiating_used_threshold` in that  call can be inlined in `G1Policy::need_to_start_conc_mark` (called by the mutator in `G1CollectedHeap::attempt_allocation_humongous`) in multiple places, and so `SoftMaxHeapSize` re-read with multiple different values in that method.

Probably an `Atomic::load(&SoftMaxHeapSize)` in the getter is sufficient for that.

The other multiple re-readings of the `soft_max_capacity()` in the safepoint seem okay - I do not think there is a way to update the value within a safepoint externally.

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

PR Comment: https://git.openjdk.org/jdk/pull/24211#issuecomment-2772496003