<div dir="ltr">Hi Thomas,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think what this suggestion overlooks is that a SoftMaxHeapSize that<br>guides used heap size will automatically guide committed size: i.e. if<br>G1 shrinks the used heap, G1 will automatically shrink (and keep) the<br>committed size.<br><br>So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.<br></blockquote><div><br></div><div>If I'm understanding this correctly - both ProposedHeapSize and (the proposed version of) SoftMaxHeapSize have similar semantics, but actually modify the heap in different ways. SoftMaxHeapSize helps us determine when to start a concurrent mark, whereas ProposedHeapSize doesn't actually trigger any GC directly, but affects the size of the heap after a GC. Is that correct? Would it make sense then to have both flags, where one helps set a trigger point for a GC, and one helps us determine the heap size we are targeting after the GC? I might also be missing some nuances here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I.e. if I understand this correctly: allowing a higher GC overhead,<br>automatically shrinks the heap.</blockquote><div><br></div><div>Exactly - in practice, tuning this one parameter up (the target gc cpu overhead) correlates with decreasing both the average as well as maximum heap usage for a java program.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I noticed the same with the patch attached to the SoftMaxHeapSize CR<br>(<a href="https://bugs.openjdk.org/browse/JDK-8236073" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8236073</a>) discounting effects of<br>Min/MaxHeapFreeRatio (i.e. if you remove it,<br><a href="https://bugs.openjdk.org/browse/JDK-8238686" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8238686</a> explains the issue).<br>In practice, these two flags prohibit G1 from adjusting the heap unless<br>the SoftMaxHeapSize change is very large.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>So I would prefer to only think of an alternative to SoftMaxHeapSize if<br>it has been shown that it does not work.</blockquote><div><br></div><div>Given that you have a much stronger mental model than I do of how all these flags fit together in the context of G1 GC, perhaps it would be helpful to schedule some time to chat in person! I think that would help clarify things much more quickly than email. To be clear - I have no reason to doubt that SoftMaxHeapSize does not work. On the other hand, could we possibly make use of both flags? For example, could SoftMaxHeapSize potentially be a good replacement for our periodic GC?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There is the nit that unlike in this implementation of ProposedHeapSize,<br>SoftMaxHeapSize will not cause uncommit below MinHeapSize. This is<br>another discussion on what to do about this issue - in a comment in<br><a href="https://bugs.openjdk.org/browse/JDK-8236073" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8236073</a> it is proposed to make<br>MinHeapSize manageable. </blockquote><div><br></div><div>How useful is MinHeapSize in practice? Do we need it, or can we just set it to zero to avoid having to deal with it at all?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are<br>somewhat orthogonal.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">AHS (<a href="https://openjdk.org/jeps/8329758" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8329758</a>) is about finding a reasonable<br>heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize<br>are manual external tunings.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Wdyt?</blockquote><div><br></div><div>I agree with the general idea - for us, we used a manual external flag like ProposedHeapSize because we did not implement any of the AHS logic in the JVM. (We had a separate AHS thread reading in container information and then doing the calculations, then setting ProposedHeapSize as a manageable flag.) The way I see it is that SoftMax/ProposedHeapSize is the "output" of AHS, and then SoftMax/ProposedHeapSize is the "input" for the JVM, after which the JVM uses this input to adjust its behavior accordingly. Does that align with how you see things?</div><div><br></div><div>If we do indeed implement AHS logic fully within the JVM, then we could internally manage the sizing of the heap without exposing a manageable flag. That being said, it seems to me that exposing this as a manageable flag brings the additional benefit that one could plug in their own AHS implementation that calculates target heap sizes with whatever data they want (and then passes it into the JVM via the manageable flag).</div><div><br></div><div>Again, I wonder if meeting to discuss would be efficient, and then we can update the mailing list with the results of our discussion. Let me know your thoughts!</div><div><br></div><div>Best,</div><div><br></div><div>~ Jonathan</div><div> </div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 8, 2024 at 8:35 AM Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com" target="_blank">thomas.schatzl@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jonathan,<br>
<br>
On 05.10.24 00:39, Jonathan Joo wrote:<br>
> Hi All,<br>
> <br>
> As Kirk mentioned in his email "Aligning the Serial collector with ZGC <br>
> <<a href="https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-September/049616.html" rel="noreferrer" target="_blank">https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-September/049616.html</a>>", we are also working on adding Adaptable Heap Sizing (AHS) to G1.<br>
> <br>
> I created a draft Pull Request <br>
> <<a href="https://github.com/openjdk/jdk/pull/20783" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/20783</a>> and received some comments <br>
> on it already, including the following points:<br>
>  <br>
>  1. I should Convert CurrentMaxExpansionSize to CurrentMaxHeapSize.<br>
> <br>
>  2. SoftMaxHeapSize, as implemented in the PR, is different from the<br>
>     original intent.<br>
><br>
>  3. We need some sort of global memory pressure to enforce heap shrinkage.<br>
 ><br>
 ><br>
> The first point I already addressed on the pull request, and I agree <br>
> that CurrentMaxHeapSize works well :)<br>
>  <br>
> Regarding the second point, we had some discussions already outside of <br>
> this mailing list, but if I were to summarize the main ideas, they are:<br>
> <br>
>  1. The intent of SoftMaxHeapSize initially was for the GC to use this<br>
>     value as a guide for when to start concurrent GC.<br>
> <br>
>  2. Our implementation of SoftMaxHeapSize (in the PR) currently behaves<br>
>     more like a ProposedHeapSize, where whenever we shrink and expand<br>
>     the heap, we try to set the heap size to ProposedHeapSize,<br>
>     regardless of the value of MinHeapSize.<br>
> <br>
>  3. We need to ensure that the heap regularly approaches the value of<br>
>     ProposedHeapSize by introducing some sort of periodic GC, which we<br>
>     have a Google-internal patch for, and is not yet present in the PR.<br>
>     If we are in alignment that this makes sense, I can try adding this<br>
>     as a separate PR.<br>
<br>
I think what this suggestion overlooks is that a SoftMaxHeapSize that <br>
guides used heap size will automatically guide committed size: i.e. if <br>
G1 shrinks the used heap, G1 will automatically shrink (and keep) the <br>
committed size.<br>
<br>
So ProposedHeapSize seems to be very similar to SoftMaxHeapSize.<br>
<br>
<br>
> As a separate point - Kirk mentioned in his email that he aims to <br>
> introduce an adaptive size policy where "Heap should be large enough to <br>
> minimize GC overhead but not large enough to trigger OOM". I think from <br>
> our experience in G1, we don't actively try to minimize GC overhead, as <br>
> we find that maintaining a higher GC overhead often results in overall <br>
> RAM savings >> CPU usage.<br>
> <br>
<br>
I.e. if I understand this correctly: allowing a higher GC overhead, <br>
automatically shrinks the heap.<br>
<br>
> I think as a general summary - the way I see it, there's value in <br>
> creating a simplified system where we control the majority of JVM <br>
> behavior simply with two flags - the maximum heap size (to prevent <br>
> OOMs), and a target heap size, which is our calculation of an "optimal" <br>
> size based on our understanding of the environment. The exact <br>
> calculations for this optimal size may change depending on <br>
> workload/preference, but what we are trying to do at this point in time <br>
> is allow for a way to pass in some calculation for "optimal heap size" <br>
> and have G1 react to it in a meaningful way. I acknowledge that the <br>
> current JVM behavior (as implemented in my PR) may be suboptimal in <br>
> terms of getting the heap to get to and stay at this "optimal heap <br>
> size". However, even with the basic implementation of passing this value <br>
> to shrinks/expands and only triggering resizes on Remarks/Full GCs, <br>
> we've seen dramatic improvements in heap behavior at Google, compared to <br>
> the current G1.<br>
<br>
I noticed the same with the patch attached to the SoftMaxHeapSize CR <br>
(<a href="https://bugs.openjdk.org/browse/JDK-8236073" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8236073</a>) discounting effects of <br>
Min/MaxHeapFreeRatio (i.e. if you remove it, <br>
<a href="https://bugs.openjdk.org/browse/JDK-8238686" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8238686</a> explains the issue).<br>
In practice, these two flags prohibit G1 from adjusting the heap unless <br>
the SoftMaxHeapSize change is very large.<br>
<br>
So I would prefer to only think of an alternative to SoftMaxHeapSize if <br>
it has been shown that it does not work.<br>
<br>
There is the nit that unlike in this implementation of ProposedHeapSize, <br>
SoftMaxHeapSize will not cauase uncommit below MinHeapSize. This is <br>
another discussion on what to do about this issue - in a comment in <br>
<a href="https://bugs.openjdk.org/browse/JDK-8236073" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8236073</a> it is proposed to make <br>
MinHeapSize manageable.<br>
> I know there was some disagreement about the addition of this new <br>
> "optimal heap size" flag, and I agree that SoftMaxHeapSize is probably <br>
> not the right flag to represent this value. But I'd like to get some <br>
> thoughts on whether the above summary seems like a reasonable way of <br>
> reasoning about G1 AHS. If we agree, then we can always iteratively <br>
> improve the JVM logic to better adhere to the optimal heap size. But <br>
> it's not yet clear to me whether people are onboard the idea of having <br>
> this "optimal heap size" calculation at all, since perhaps this <br>
> functionality could be covered in other, existing ways.<br>
<br>
I (still) believe that AHS and SoftMaxHeapSize/ProposedHeapSize are <br>
somewhat orthogonal.<br>
<br>
AHS (<a href="https://openjdk.org/jeps/8329758" rel="noreferrer" target="_blank">https://openjdk.org/jeps/8329758</a>) is about finding a reasonable <br>
heap size, and adjust on external "pressure". SoftMax/ProposedHeapSize <br>
are manual external tunings.<br>
<br>
Wdyt?<br>
<br>
   Thomas<br>
<br>
</blockquote></div>