<div dir="ltr">Hi Thomas,<div><br></div><div>The points you mentioned make sense to me! There are some nuances that I'd like to dig into further to make sure that we are aligned. I think to summarize - I'm not sure exactly how SoftMaxHeapSize is intended to work, whereas we have experimented with ProposedHeapSize at Google already, so I want to bridge my gap in understanding there. </div><div><br></div><div>I appreciate you offering to meet and discuss! As far as meeting time - I'm currently in US Pacific time, but flexible in terms of when we meet. (I am generally awake from 9am-1am PT, so I am good to meet any time in that time period -- please let me know what time works best for you.) Tuesday and Thursday of the coming week I have the most availability, but if you have any other dates/times in mind, I can let you know whether that works for me.</div><div><br></div><div>Best,</div><div><br></div><div>~ Jonathan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 14, 2024 at 2:52 AM Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com">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,<br>
<br>
On 11.10.24 09:16, Jonathan Joo wrote:<br>
> Hi Thomas,<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>
> If I'm understanding this correctly - both ProposedHeapSize and (the <br>
> proposed version of) SoftMaxHeapSize have similar semantics, but <br>
> actually modify the heap in different ways. SoftMaxHeapSize helps us <br>
> determine when to start a concurrent mark, whereas ProposedHeapSize <br>
> doesn't actually trigger any GC directly, but affects the size of the <br>
> heap after a GC. Is that correct? Would it make sense then to have both <br>
> flags, where one helps set a trigger point for a GC, and one helps us <br>
> determine the heap size we are targeting after the GC? I might also be <br>
> missing some nuances here.<br>
<br>
I think SoftMaxHeapSize (or actually either) will result in <br>
approximately the same behavior. The difference is in intrusiveness.<br>
<br>
ProposedHeapSize forcefully attempts to decrease the committed heap size <br>
and then the rest of the "heap sizing machinery" follows, while <br>
SoftMaxHeapSize gives a target for the "heap sizing machinery" and <br>
committed heap size follows.<br>
<br>
ProposedHeapSize has the following disadvantages (as implemented):<br>
<br>
- since it forces committed heap size, I expect that in case you are <br>
close or above that target, you can get frequent uncommits/attempts to <br>
uncommit which waste cpu cycles.<br>
<br>
Hopefully, by giving the heap sizing machinery a goal, it will itself <br>
determine a sustainable committed memory level without too frequent <br>
commits and uncommits.<br>
<br>
- for some reason it does not allow less memory to be committed than <br>
proposed (but still larger than MinHeapSize). This can be inefficient <br>
wrt to memory usage.<br>
I.e. it basically disables other heap sizing afaict.<br>
<br>
- (that's more a nit) the use of "0" as special marker for <br>
SoftMaxHeapSize is unexpected.<br>
<br>
This mechanism kind of feels like a very blunt tool to get the desired <br>
effect (a certain committed heap) without caring about other goals. It <br>
may be necessary to pull out the immediately un/commit hammer in some <br>
situations, and imho, let's not give that hammer to users as the first <br>
option to screw themselves.<br>
<br>
> <br>
> I.e. if I understand this correctly: allowing a higher GC overhead,<br>
> automatically shrinks the heap.<br>
> <br>
> <br>
> Exactly - in practice, tuning this one parameter up (the target gc cpu <br>
> overhead) correlates with decreasing both the average as well as maximum <br>
> heap usage for a java program.<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><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><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>
> <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>
> <br>
> Given that you have a much stronger mental model than I do of how all <br>
> these flags fit together in the context of G1 GC, perhaps it would be <br>
> helpful to schedule some time to chat in person! I think that would help <br>
> clarify things much more quickly than email. To be clear - I have no <br>
> reason to doubt that SoftMaxHeapSize does not work. On the other hand, <br>
> could we possibly make use of both flags? For example, could <br>
> SoftMaxHeapSize potentially be a good replacement for our periodic GC?<br>
<br>
Not sure what periodic GC has to do with SoftMaxHeapSize.<br>
<br>
> <br>
> 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><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>
> <br>
> <br>
> How useful is MinHeapSize in practice? Do we need it, or can we just set <br>
> it to zero to avoid having to deal with it at all?<br>
<br>
I think you are mixing AHS (give decent heap sizing in presence of <br>
external memory pressure) and getting "optimal" heap sizing (or iow <br>
"steering heap size" externally).<br>
<br>
AHS is mostly about the user not doing/setting any heap sizes; in this <br>
case just having min heap size very low is just fine just as suggested <br>
in the JEP.<br>
<br>
SoftMaxHeapSize (and ProposedHeapSize) is about the user setting a <br>
particular goal according to his whims. It is still interesting to set <br>
-Xms==-Xmx for e.g. fast startup or during heavy activity; however if an <br>
external system decides that it is useful to intermittently save memory <br>
up to a certain level, then follow that guidance.<br>
<br>
The mechanism to internally follow that guidance can be used by AHS.<br>
<br>
<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><br>
> <<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>
> <br>
> Wdyt?<br>
> <br>
> <br>
> I agree with the general idea - for us, we used a manual external flag <br>
> like ProposedHeapSize because we did not implement any of the AHS logic <br>
> in the JVM. (We had a separate AHS thread reading in container <br>
> information and then doing the calculations, then setting <br>
> ProposedHeapSize as a manageable flag.) The way I see it is that <br>
> SoftMax/ProposedHeapSize is the "output" of AHS, and then <br>
> SoftMax/ProposedHeapSize is the "input" for the JVM, after which the JVM <br>
> uses this input to adjust its behavior accordingly. Does that align with <br>
> how you see things?<br>
<br>
As mentioned in the other thread, SoftMaxHeapSize can be used by AHS to <br>
get heap to a certain level (based on memory pressure), but there is <br>
also that external entity that can modify SoftMaxHeapSize to adjust VM <br>
behavior.<br>
<br>
So ultimately there will be multiple inputs for target heap size (and <br>
probably I'm forgetting one or the other):<br>
<br>
* External memory pressure (AHS) (*)<br>
<br>
* CurrentMaxHeapSize<br>
<br>
* SoftMaxHeapSize<br>
<br>
* CPU usage (existing GCTimeRatio based policy)<br>
<br>
* other *HeapSize flags<br>
<br>
that need to be merged into some target heap level using some policy.<br>
<br>
After knowing that level, the VM needs to decide on a proper reaction, <br>
which might be anything from just setting internal IHOP goal, to <br>
(un-)committing memory directly, to doing the appropriate garbage <br>
collection in a "timely" fashion (which is where the regular periodic <br>
gc/marking comes in) or anything inbetween.<br>
<br>
(*) I am aware that the AHS JEP not only includes reaction on external <br>
memory pressure but also the merging of goals for different sources; <br>
some of them are ZGC specific. Some of them are already implemented in <br>
G1. So for this discussion it is imo useful to limit "AHS" in G1 context <br>
to things that G1 does not do. Ie. "return another goal based on <br>
external memory pressure", "min/max heap size defaults(!)", and "adjust <br>
adaptive sizing".<br>
<br>
> If we do indeed implement AHS logic fully within the JVM, then we could <br>
> internally manage the sizing of the heap without exposing a manageable <br>
> flag. That being said, it seems to me that exposing this as a manageable <br>
> flag brings the additional benefit that one could plug in their own AHS <br>
> implementation that calculates target heap sizes with whatever data they <br>
> want (and then passes it into the JVM via the manageable flag).<br>
> <br>
> Again, I wonder if meeting to discuss would be efficient, and then we <br>
> can update the mailing list with the results of our discussion. Let me <br>
> know your thoughts!<br>
<br>
It's fine with me to meet to recap and discuss above; please suggest <br>
some time.<br>
<br>
Hth,<br>
Thomas<br>
</blockquote></div>