Moving Forward with AHS for G1

[Man Cao]

Re Thomas's comments:

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.


Thanks. Should I edit https://bugs.openjdk.org/browse/JDK-8204088 in place
to change it to a CSR, or do you prefer creating a separate issue?

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.


I feel like both approaches have additional problems:
For the first approach, even with a translation mechanism, it still has the
problem of GCTimeRatio and Min/MaxHeapFreeRatio overriding each other. I
think the only solution is to translate Min/MaxHeapFreeRatio directly to a
value for GCTimeRatio, as well as making GCTimeRatio a manageable flag.
Agree that the effort to implement this approach is nontrivial.
For the second approach, Min/MaxHeapFreeRatio are pretty popular flags for
Parallel GC, so it could be difficult to remove them for Parallel GC.

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.


I think removing support for Min/MaxHeapFreeRatio only for G1 is feasible,
as long as we provide a replacement approach. Some high-level guidance like
"if you set Min/MaxHeapFreeRatio to small values such as XX, try lowering
GCTimeRatio to YY" may be acceptable. The downside is that it requires
users of Min/MaxHeapFreeRatio to re-tune JVM parameters.
One unresolved use case is dynamically changing Min/MaxHeapFreeRatio due to
them being manageable. Perhaps we could make GCTimeRatio manageable? But
Parallel GC and Shenandoah also use GCTimeRatio, so it could be difficult.
Or if we reconsider the high-precedence SoftMaxHeapSize implementation (
https://github.com/openjdk/jdk/pull/24211), perhaps users who dynamically
set Min/MaxHeapFreeRatio could move to set SoftMaxHeapSize instead.

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


The use case is to create a process snapshot image via CRIU
(checkpoint/restore), like what https://openjdk.org/projects/crac does.
The application wants G1 to shrink the heap as much as possible, to reduce
the size of the snapshot. It sets both flags to zero, performs several
System.gc(), then sets both flags back to previous values, then creates the
snapshot.

-Man
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250410/9d475773/attachment.htm>