Moving Forward with AHS for G1

[Thomas Schatzl]

Hi Man,

On 09.04.25 09:44, Man Cao wrote:
> Hi all,
> 
> Thank you Thomas for creating the umbrella CR at https:// 
> bugs.openjdk.org/browse/JDK-8353716 <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.

I think this is the best way forward. There is no need for a JEP from me 
either.

Exact behavior in various situations needs to be defined in the CSR.

> 
> 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?

After searching the web a little, it seems that these flags are actually 
in use, and recommended to be used (e.g. in default settings).

So we need some transition strategy to get off them, and can't just remove.

One option is to translate these options into other values impacting 
heap size "similarly". E.g. have Min/MaxHeapFreeRatio translate to 
internal pressure at the time the changes are noticed, but that is just 
a potential solution that hand-waves away the effort for that.

Then start deprecating and remove; depends a little on how useful (or 
how much in the way) they are for Serial and Parallel GC (other 
collectors don't support them). It is unlikely that ZGC and Shenandoah 
will adopt these.

Even already in JDK-8238687 Min/MaxHeapFreeRatio happily work to counter 
the cpu based sizing, so some solution needs to be found there already.

That change will already be quite disruptive in terms of impact on heap 
sizing, so another option is to remove support in G1.

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

What would be the use case for setting it to these values?

There seem to be little upside and lots of downside for this choice, 
because it likely causes a lot of GC activity since the VM will need GC 
to expand the heap little by little all the time, and full gc/Remark 
will immediately reset these expansion efforts.

Thomas