Moving Forward with AHS for G1

[Erik Osterlund]

Hi Man,

Sorry to butt in. A high level question about the AHS plan for G1… are we interested in the
intermediate functionality (SoftMaxHeapSize and CurrentMaxHeapSize), or is it AHS that
we are interested in?

The reason I ask is that each incremental feature comes with some baggage due to being
a (somewhat) static and manually set limit, which the AHS solution won’t need to deal with.

For example, it’s unclear how a *static* SoftMaxHeapSize should behave when the livee set
is larger than the limit. While that can maybe be solved in some reasonable way, it’s worth
noting that AHS won’t need the solution, because there it’s a dynamic limit that the GC simply
won’t set lower than the memory usage after GC. It will however get in the way because the
user can now also set a SoftMaxHeapSize that conflicts with the AHS soft heap size that
the JVM wants to use, and then we gotta deal with that.

Similarly, the CurrentMaxHeapSize adds another way for users to control (read: mess up)
the JVM behaviour that we need to respect. In the end, AHS will compute this dynamically
instead depending on environment circumstances. I suspect the fact that it can also be
manually set in a way that conflicts with what the JVM wants to do, will end up being a pain.

I’m not against the plan of building these incremental features, especially if we want them
in isolation. But if it’s AHS we want, then I wonder if it would be easier to go straight for what
we need for AHS without the intermediate user exposed steps, because they might introduce
unnecessary problems along the way.

My 50c, no strong opinion though.

/Erik

On 9 Apr 2025, at 09:44, Man Cao <manc at google.com> wrote:

Hi all,

Thank you Thomas for creating the umbrella CR at https://bugs.openjdk.org/browse/JDK-8353716.
While waiting a bit on SoftMaxHeapSize PR (https://github.com/openjdk/jdk/pull/24211) to see if others have feedback, I could start working on CurrentMaxHeapSize (https://bugs.openjdk.org/browse/JDK-8204088).
I also agree that CurrentMaxHeapSize may not need a JEP due to its small size and low complexity. Should it proceed similarly to how SoftMaxHeapSize was introduced? I.e, https://bugs.openjdk.org/browse/JDK-8222145, and creating a CSR (https://bugs.openjdk.org/browse/JDK-8222181) for it.

Separately, for removing support for Min/MaxHeapFreeRatio for G1 (mentioned in https://bugs.openjdk.org/browse/JDK-8353716 and https://bugs.openjdk.org/browse/JDK-8238686), how do we handle existing users that set these two flags?
(We have very few internal users setting these two flags. But yesterday I ran into a use case that sets -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=0 for G1...)

Best,
Man

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250409/6a9db860/attachment.htm>