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

[Ivan Walulya]

On Thu, 3 Apr 2025 06:27:22 GMT, Man Cao <manc at openjdk.org> wrote:

>     1. Users that set `SoftMaxHeapSize` expect it to be effective to limit heap size. The JVM should do its best to respect user's request. As [JDK-8222181](https://bugs.openjdk.org/browse/JDK-8222181) mentions: "When -XX:SoftMaxHeapSize is set, the GC should strive to not grow heap size beyond the specified size, unless the GC decides it's necessary to do so."  We might interpret "GC decides it's necessary" differently. I think the real necessary case is "the JVM will throw OutOfMemoryError if it does not grow the heap", instead of "the JVM will violate `MinHeapFreeRatio`/`MaxHeapFreeRatio`/`GCTimeRatio` if it does not grow the heap".

In the current approach, it is not that we are respecting the user's request, we are violating the request just that we do this only during GCs. So eventually you have back to back GCs that will expand the heap to whatever heapsize the application requires. My interpretation of `SoftMaxHeapSize` is that we can meet this limit where possible, but also exceed the limit if required. So I propose we take the same approach as used in other GCs where `SoftMaxHeapSize` is used as a parameter for setting GC pressure but not as a limit to allocations. 

> 
>     3. Issues with expansion after young collections from `GCTimeRatio`. `MinHeapFreeRatio`/`MaxHeapFreeRatio` have no effect on how much G1 expands the heap after young collections. Users need to tune `GCTimeRatio` if they want to make G1 expand less aggressively, otherwise aggressive expansion would defeat the purpose of `SoftMaxHeapSize`. However, `GCTimeRatio` is not a manageable flag, so it cannot be changed at run time. If `SoftMaxHeapSize` has precedence, we don't need to bother making `GCTimeRatio` manageable and asking users to tune it at run time. (This is somewhat related to [JDK-8349978](https://bugs.openjdk.org/browse/JDK-8349978) and [email thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-February/051004.html). )

Agreed, these ratios are problematic, and we should find a solution that removes them. We also need to agree on the purpose of `SoftMaxHeapSize`, my understanding is that `SoftMaxHeapSize` is meant for the application to be handle spikes in allocations and and quickly release the memory if no longer required. If `SoftMaxHeapSize` has precedence over`GCTimeRatio`, then G1 is changing the objective from balancing latency and throughput to optimizing for memory usage.

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

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