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

[Man Cao]

On Tue, 30 Sep 2025 19:32:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to implement `SoftMaxHeapSize` for G1.
>> 
>> Main change is that `SoftMaxHeapSize` now impacts the `G1IHOPControl::target_occupancy()`, i.e. the amount of bytes G1 when reclaim should start.
>> 
>> Most of the other changes are just about updating logging/JFR and making sure that the `SoftMaxHeapSize` values are consistent across calls.
>> 
>> Testing: tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * align MinHeapSize to heap alignment to avoid issues with conflicting MinHeapSize and SoftMaxHeapSize

Responding to @tschatzl's comment in https://bugs.openjdk.org/browse/JDK-8236073:
> SoftMaxHeapSize just affects the target heap size for scheduling concurrent marks. GCTimeRatio sets the target as well, so the result is basically MIN(SoftMaxHeapSize, GCTimeRatio-based-target).

I have not verified, but could this problematic feedback loop happen?
User sets a **low** `SoftMaxHeapSize` value, then G1 starts to trigger more concurrent marks and incremental collections, then GC overhead becomes higher. Then G1 observes that the actual GC overhead is above the `GCTimeRatio` target, so it **expands** the heap. Thus, setting a small `SoftMaxHeapSize`  makes G1 expand the heap further,

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

PR Comment: https://git.openjdk.org/jdk/pull/27524#issuecomment-3353942624