<div dir="ltr"><div dir="ltr">Hello all,<div><br></div><div>the main target of these two patches is highly dynamic environments, where the application should get, at each moment, just enough</div><div>resources to run. Consider the following stack: application - JVM - customer container - cloud provider VM. The container is charged for</div><div>memory consumption. Samples are taken frequently.</div><div><br></div><div>The CurrentMaxHeapSize idea is to allow the customer to inform the application of how much memory it should use at most. This is necessary</div><div>because many applications will read the max heap size and will just use all the available memory for example, to cache data. With this patch,</div><div>we give the application an opportunity to read the new max heap size, which will return the CurrentMaxHeapSize containing the value that </div><div>the user wants.</div><div><br></div><div>The difference here from using the update_target_occupancy (besides potential overshooting) is that this is not visible to the application </div><div>(please correct me if this not true). In other words, if I change the threshold at runtime, can the application see the change?</div><div><br></div><div>Probably a good solution is somewhere in the middle, where we can let the application know the current limit and maybe be a bit more</div><div>aggressive when we get closer to the threshold (current max heap size). </div><div><br></div><div>What do you think?</div><div><br></div><div>Cheers,</div><div>rodrigo</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Thomas Schatzl <<a href="mailto:thomas.schatzl@oracle.com">thomas.schatzl@oracle.com</a>> escreveu no dia quinta, 11/04/2019 à(s) 12:11:<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 Ruslan,<br>
<br>
On Wed, 2019-04-10 at 18:53 +0200, Ruslan Synytsky wrote:<br>
> So happy to get this long-awaited improvement! <br>
> <br>
> There are additional materials related to the same issue: JEP draft:<br>
> Dynamic Max Memory Limit<br>
> <a href="https://openjdk.java.net/jeps/8204088" rel="noreferrer" target="_blank">https://openjdk.java.net/jeps/8204088</a><br>
> <a href="https://bugs.openjdk.java.net/browse/JDK-8204088" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8204088</a><br>
<br>
The most recent webrev is at <br>
<a href="http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/</a> (I will call it<br>
CurrentMaxHeapSize approach in the following); note that that change<br>
implements something slightly different: it modifies the current *hard*<br>
max heap size. Which means that the heap size, once successfully set,<br>
will not go over this value, and if the application does, throw an<br>
OOME.<br>
<br>
The -XX:SoftMaxHeapSize value, is only a goal for the collector to<br>
start reclaiming memory only. It may still, at will, use more memory<br>
(up to regular MaxHeapSize).<br>
Of course, that overshoot will depend on the collector.<br>
<br>
The effect is similar, but not exactly that in border cases; if there<br>
were somebody to work on this (maybe Lin from the other sub-thread or<br>
you?), so would something like that an acceptable solution for you too?<br>
<br>
I believe for this to work (and this is mostly a guess), it may be<br>
sufficient to call G1IHOPControl::update_target_occupancy() with the<br>
new SoftMaxHeapSize flag at certain places(*) instead of modifying the<br>
actual maximum heap sizes like in the other attempt.<br>
The heap sizing algorithm should then automatically do the right thing,<br>
particularly in combination with JEP 346.<br>
<br>
(*) Being very conservative, only at (induced) safepoints; however<br>
since this would only change the timing when and how gcs are triggered,<br>
there should not be too much harm otherwise.<br>
<br>
This is different to changing the current (hard) max heap size; more<br>
care may needs to be taken (i.e. more analysis) there, that's why it<br>
has not been picked up by the Oracle gc team at this time.<br>
<br>
There is at least one, if not more, ways of misusing the<br>
CurrentMaxHeapSize approach that comes to my mind (totally random):<br>
what would be the expectation of the user if he updated<br>
CurrentMaxHeapSize in an OOME handler caused by reaching<br>
CurrentMaxHeapSize?<br>
<br>
In addition to that, some details need to be worked out what should<br>
happen when, e.g. should memory automatically be uncommitted asap, or<br>
some time later? Unfortunately JDK-8222145 also does not give an<br>
answer.<br>
<br>
> Rodrigo Bruno implemented a patch for G1 already. The algorithm is<br>
> described at the research <br>
> <a href="http://ranger.uta.edu/~jrao/papers/ISMM18.pdf" rel="noreferrer" target="_blank">http://ranger.uta.edu/~jrao/papers/ISMM18.pdf</a> (flag<br>
> name CurrentMaxMemory).  <br>
> <br>
> Should we join the efforts and deliver it together? <br>
<br>
We would be happy for contributions :) - unfortunately we at Oracle at<br>
this time do not have the time for significant work on it similar to<br>
JEP 346 right now.<br>
<br>
Thanks,<br>
  Thomas<br>
<br>
<br>
</blockquote></div></div>