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

[Thomas Schatzl]

On Tue, 1 Apr 2025 08:44:55 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:
> 
>   Revise test summary

Initial comments.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2066:

> 2064: size_t G1CollectedHeap::soft_max_capacity() const {
> 2065:   return clamp(align_up(SoftMaxHeapSize, HeapAlignment), MinHeapSize,
> 2066:                max_capacity());

Maybe this clamping of `SoftMaxHeapSize` should be part of argument processing.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 1203:

> 1201:   size_t max_capacity() const override;
> 1202: 
> 1203:   // Print the soft maximum heap capacity.

Suggestion:

  // Returns the soft maximum heap capacity.

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`).

test/hotspot/jtreg/gc/g1/TestSoftMaxHeapSize.java line 29:

> 27:  * @test
> 28:  * @bug 8236073
> 29:  * @requires vm.gc.G1 & vm.opt.ExplicitGCInvokesConcurrent != true

It's nicer to put and-ed conditions in separate lines.

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()`?

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24211#pullrequestreview-2731934928
PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2022415626
PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2022415016
PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2022430412
PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2022434814
PR Review Comment: https://git.openjdk.org/jdk/pull/24211#discussion_r2022438436