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

[Man Cao]

On Tue, 1 Apr 2025 08:48:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test summary
>
> src/hotspot/share/gc/g1/g1IHOPControl.cpp line 119:
> 
>> 117:   return (size_t)MIN2(
>> 118:     G1CollectedHeap::heap()->soft_max_capacity() * (100.0 - safe_total_heap_percentage) / 100.0,
>> 119:     _target_occupancy * (100.0 - _heap_waste_percent) / 100.0
> 
> This looks wrong. G1ReservePercent is in some way similar to soft max heap size, intended to keep the target below the real maximum capacity.
> I.e. it is not intended that G1 keeps another reserve of G1ReservePercent size below soft max capacity (which is below maximum capacity).
> 
> There has been some internal discussion about whether the functionality of G1ReservePercent and SoftMaxHeapSize is too similar to warrant the former, but removing it is another issue.
> 
> Imo, SoftMaxHeapSize should be an separate, actual target for this calculation. (`default_conc_mark_start_threshold()` also does not subtract `G1ReservePercent` from `SoftMaxHeapSize`).

Thanks. Yes, that makes sense. Now it uses `MIN3` to take `soft_max_capacity()` as a separate constraint.

> test/hotspot/jtreg/gc/g1/TestSoftMaxHeapSize.java line 46:
> 
>> 44:   private static final long ALLOCATED_BYTES = 20_000_000; // About 20M
>> 45:   private static final long MAX_HEAP_SIZE =
>> 46:       200 * 1024 * 1024; // 200MiB, must match -Xmx on command line.
> 
> Is it possible to get that value from the `MemoryMXBean` instead of relying on manual update? I.e. `getMax()`?

Yes, it is a good idea. Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2023659889
PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2023660401