Further discussion on Adaptable Heap Sizing with G1

[Jonathan Joo]

Hi All,


As Kirk mentioned in his email "Aligning the Serial collector with ZGC
<https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-September/049616.html>",
we are also working on adding Adaptable Heap Sizing (AHS) to G1.


I created a draft Pull Request <https://github.com/openjdk/jdk/pull/20783> and
received some comments on it already, including the following points:



   1.

   I should Convert CurrentMaxExpansionSize to CurrentMaxHeapSize.
   2.

   SoftMaxHeapSize, as implemented in the PR, is different from the
   original intent.
   3.

   We need some sort of global memory pressure to enforce heap shrinkage.


The first point I already addressed on the pull request, and I agree that
CurrentMaxHeapSize works well :)


Regarding the second point, we had some discussions already outside of this
mailing list, but if I were to summarize the main ideas, they are:

   1.

   The intent of SoftMaxHeapSize initially was for the GC to use this value
   as a guide for when to start concurrent GC.
   2.

   Our implementation of SoftMaxHeapSize (in the PR) currently behaves more
   like a ProposedHeapSize, where whenever we shrink and expand the heap, we
   try to set the heap size to ProposedHeapSize, regardless of the value of
   MinHeapSize.
   3.

   We need to ensure that the heap regularly approaches the value of
   ProposedHeapSize by introducing some sort of periodic GC, which we have a
   Google-internal patch for, and is not yet present in the PR. If we are in
   alignment that this makes sense, I can try adding this as a separate PR.


For the third point,  Similar to ZGC's -XX:ZGCPressure, we use
target_gc_cpu_overhead (along with periodic GC) to control heap shrinkage
by adjusting ProposedHeapSize. This allows users to balance RAM and CPU
usage. Note that this isn't yet present in the PR, since the PR only
includes the JVM changes introducing the CurrentMaxHeapSize and
ProposedHeapSize flags. The logic to actually dynamically calculate the
value of ProposedHeapSize would be a separate change, and can be iterated
on.



As a separate point - Kirk mentioned in his email that he aims to introduce
an adaptive size policy where "Heap should be large enough to minimize GC
overhead but not large enough to trigger OOM". I think from our experience
in G1, we don't actively try to minimize GC overhead, as we find that
maintaining a higher GC overhead often results in overall RAM savings >>
CPU usage.



I think as a general summary - the way I see it, there's value in creating
a simplified system where we control the majority of JVM behavior simply
with two flags - the maximum heap size (to prevent OOMs), and a target heap
size, which is our calculation of an "optimal" size based on our
understanding of the environment. The exact calculations for this optimal
size may change depending on workload/preference, but what we are trying to
do at this point in time is allow for a way to pass in some calculation for
"optimal heap size" and have G1 react to it in a meaningful way. I
acknowledge that the current JVM behavior (as implemented in my PR) may be
suboptimal in terms of getting the heap to get to and stay at this "optimal
heap size". However, even with the basic implementation of passing this
value to shrinks/expands and only triggering resizes on Remarks/Full GCs,
we've seen dramatic improvements in heap behavior at Google, compared to
the current G1.


I know there was some disagreement about the addition of this new "optimal
heap size" flag, and I agree that SoftMaxHeapSize is probably not the right
flag to represent this value. But I'd like to get some thoughts on whether
the above summary seems like a reasonable way of reasoning about G1 AHS. If
we agree, then we can always iteratively improve the JVM logic to better
adhere to the optimal heap size. But it's not yet clear to me whether
people are onboard the idea of having this "optimal heap size" calculation
at all, since perhaps this functionality could be covered in other,
existing ways.


Thank you!


~ Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20241004/4404d378/attachment-0001.htm>