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

[Monica Beckwith]

On Fri, 4 Apr 2025 09:01:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Meanwhile, @mo-beck do you guys have preference on how SoftMaxHeapSize should work?

Thanks for the thoughtful work here — this PR is a solid step toward strengthening G1’s memory footprint management, and I support it.

This patch adds support for `SoftMaxHeapSize` in both expansion and shrinkage paths, as well as IHOP calculation, ensuring it's part of the regular heap policy logic. As I outlined in my [original note](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050191.html) and follow-up on [AHS integration](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-March/051619.html), my intent has been to use `SoftMaxHeapSize` as a guiding input — a soft signal — within a broader dynamic heap sizing controller that considers GC overhead, mutator behavior, and memory availability. This patch lays the groundwork for that direction.

The behavior when the live set exceeds the soft target has come up in the discussion. My view remains that the heap should be influenced by the value, not strictly bound to it. That’s the balance I’ve been aiming for in describing how it integrates into the control loop — SoftMax helps inform decisions, but doesn’t unconditionally restrict them.

I agree that we’ll want to follow up with logic that can respond to GC pressure and workload needs, to avoid any unintended performance issues. I’ll update [JDK-8353716](https://bugs.openjdk.org/browse/JDK-8353716) to reflect this, and I’ll continue the thread on the mailing list to coordinate the next phase.

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

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