<div dir="ltr">Dear Thomas, thank you for supporting this initiative, your <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">efforts and time.</span> Please review my comments inline.  <br><div class="gmail_extra"><br><div class="gmail_quote">On 24 May 2018 at 12:03, Thomas Schatzl <span dir="ltr"><<a href="mailto:thomas.schatzl@oracle.com" target="_blank">thomas.schatzl@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rodrigo, Ruslan,<br>
<br>
  first, sorry for the late reply. I have been travelling, so a bit<br>
short on time on thinking about and looking through this.<br>
<br>
Thanks for your contribution. I think these ideas are a very<br>
interesting and generally useful additions to the collector and/or<br>
community.</blockquote><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255)">A long story short :). The first thoughts about elasticity of JVM came to our team in January 2011. I reached Aleksey Shipilëv to discuss the idea. I was looking for an advice how to make it happen. We found no "out-of-box" solution at that time. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Unfortunately Full GC is the only way till now to tell JVM to give back unused but committed heap. <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Parallel GC, which was default, is not friendly with RAM consumption at all. </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">G1 was not production ready.</span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> So we had a changeling time.<span> </span></span></span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">A little bit later we figured out that it's possible to achieve the required behavior with a javagent that monitors ram usage and force GC when the application is not busy. </span>We made an experiment during several years analyzing how customers react on the vertical scaling. The result was impressive, better than we expected. We never had complains, contrary many customers gave a positive feedback because they simply saved money. Some customers even did not believe that resizing is possible! Many people still have that perception about "greedy" Java that never gives RAM back to OS.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial;background-color:rgb(255,255,255)">Nowadays this topic is even more relevant as Java and containers are a perfect couple (regardless of cgroups issues). More use cases and implementations are coming including new garbage collectors. Also, OpenJ9 provides <a href="https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.vm.80.doc/docs/xxidletuningcompactonidle.html" style="color:rgb(17,85,204)" target="_blank">-XX:+IdleTuningCompac<wbr>tOnIdle</a> and <a href="https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.vm.80.doc/docs/xsoftmx.html" style="color:rgb(17,85,204)" target="_blank">-Xsoftmx</a> already.<span> </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><wbr>We have not tested it yet,<span> </span></span>but the idea is clear, it looks similar from the description. </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">
<br>
While they may not be perfect for all use cases, they imho improve the<br>
collector sufficiently enough. Also, during reviews we may come up with<br>
smaller improvements that improve its value and catch more use cases.<br></blockquote><div>I'm pretty sure collaborating together we will come up with a better solution.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I will help you getting through the further process.<br>
<br>
So the process to get this contribution into mainline would be roughly:<br>
<br>
- get OCAs signed. As soon as you show up in the signatories list we<br>
can actually start accepting patches, i.e. review them and discuss them<br>
in more detail.<br></blockquote><div>Jelastic is listed as a contributor at <a href="http://www.oracle.com/technetwork/community/oca-486395.html" target="_blank">the <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">OCA page</span></a>, we should be fine now.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Depending on the patches' size it's probably best if you give me a<br>
webrev when your names show up there and I can make them publicly<br>
available.<br></blockquote><div>My colleague Rodrigo Bruno will take care of it.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- since these two changes seem to be very interesting for a wider<br>
public it seems that it would be useful to do JEPs for them. That might<br>
also improve the understanding and their limitations by pointing them<br>
out there, and facilitate the discussion.<br>
This is basically describing the functionality a little more formally<br>
using the template [0].<br>
<br>
I can guide you through this, but in the beginning it might be useful<br>
to just fill out the description in form of email.<br></blockquote><div>OK</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- since we will add some command line options, we will later need to go<br>
through the CSR for each of them. This is basically just letting<br>
everyone know and definition of those [1].<br></blockquote><div>OK </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">
<br>
Again, I will help you with most of the "paper"work.<br></blockquote><div>Thanks</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Following are some initial questions and thoughts to the proposals.<br>
They may be a bit confusing or somewhat unrelated though, please bear<br>
with me :)  </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
On Sat, 2018-05-19 at 19:01 +0100, Rodrigo Bruno wrote:<br>
> Dear OpenJDK community,<br>
> <br>
> Jelastic and INESC-ID have developed a patch for OpenJDK that<br>
> improves elasticity of JVM with variable loads. The detailed<br>
> description of the patch can be found below. We would like share this<br>
> patch with the community and push it to the mainstream. We believe<br>
> this work will help Java community to make JVM even better and<br>
> improve the memory resources usage (save money) in the modern cloud<br>
> environments. A more complete patch description can be found in<br>
> the paper that will be presented in ISMM 2018.<br>
<br>
<br>
> Elastic JVM Patch Description<br>
> <br>
> Elasticity is the key feature of the cloud computing. It enables to<br>
> scale resources according to application workloads timely. Now we<br>
> live in the container era. Containers can be scaled vertically on the<br>
> fly without downtime. This provides much better elasticity and<br>
> density compared to VMs. However, JVM-based applications are not<br>
> fully container-ready. The first issue is that HotSpot JVM doesn’t<br>
> release unused committed Heap memory automatically, and, therefore,<br>
> JVM can’t scale down without an explicit call of the full GC.<br>
> Secondly, it is not possible to increase the size of JVM Heap in<br>
> runtime. If your production application has an unpredictable traffic<br>
> spike, the only one way to increase the Heap size is to restart the<br>
> JVM with a new Xmx parameter. <br>
> <br>
> To solve these 2 major issues and make JVM more container friendly,<br>
> we have implemented the following improvements: i) timely reduce the<br>
> amount of unused committed memory; and ii) dynamically limit how<br>
> large the used and committed memory can grow. The patch is<br>
> implemented for the Garbage First collector.<br>
> <br>
> <br>
> Timely Reducing Unused Committed Memory<br>
> <br>
> To accomplish this goal, the HotSpot JVM was modified to periodically<br>
> trigger a full collection. Two full collections should not be<br>
> separated by more than GCFrequency seconds, a dynamically user-<br>
> defined variable. The GCFrequency value is ignored and therefore, <br>
> i.e., no full collection is triggered, if:<br>
> <br>
> GCFrequency is zero or below;<br>
<br>
A time span seems to be different to a "frequency", this seems to be<br>
more an interval like CMSTriggerInterval). Also I do not completely<br>
follow that this interval is the minimum time between two *full*<br>
collections. I would expect that any collection (or gc related pause)<br>
would reset that time.<br></blockquote><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Can we end up at the situation when small collections happen more often than <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">MinTimeBetweenGCs? Like this for example </span></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><img src="cid:ii_jhkqxua50_16392f61967db559" width="379" height="210" style="margin-right: 0px;"><br><br></span></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Then the memory shrinking will not be triggered, as I understand. Because small collections in blue area do not help, <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">we need a way to reduce the orange committed ram. So Full GC only?</span> </span></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The paper also calls this "MinTimeBetweenGCs" if I read it correctly,<br>
which is a somewhat better name.<br></blockquote><div>Ok, I added a note to the original patch description <a href="https://docs.google.com/document/d/1wLH6MyLyOZcrMweDUbvK91SZ3lHOBdZ7drNeHznlwlk/edit" target="_blank">https://docs.googl<wbr>e.com/document/d/1wLH6MyLyOZcr<wbr>MweDUbvK91SZ3lHOBdZ7drNeHznlwl<wbr>k/edit</a>. It's open for everyone to comment, just in case. <br></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">
<br>
> the average load on the host system is above MaxLoadGC. The MaxLoadGC<br>
> is a dynamically user-defined variable. This check is ignored if<br>
> MaxLoadGC is zero or below; </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What is the scale for the "load", e.g. ranging from 0.0 to 1.0, and 1.0<br>
is "full load"? Depending on that this condition makes sense.<br></blockquote><div>The logic is using <i>os::loadavg</i> and can be found at the link </div><div><a href="https://github.com/jelastic/openjdk/blob/jdk9/jdk9/hotspot/src/share/vm/runtime/vmThread.cpp#L391" target="_blank">https://github.com/jelastic/op<wbr>enjdk/blob/jdk9/jdk9/hotspot/<wbr>src/share/vm/runtime/vmThread.<wbr>cpp#L391</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The paper does not mention this.<br>
<br>
> the committed memory  is above MinCommitted bytes. MinCommitted is a<br>
> dynamically user-defined variable. This check is ignored if<br>
> MinCommitted is zero or below;<br>
<br>
While this is a different concern, have you ever considered using<br>
MinHeapSize or InitialHeapSize here?<br></blockquote><div>Good point. I think we can replace <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">MinCommitted</span> with Xms. We added it just in case if Xms is set to a low number (for example 32m), then memory usage grows up significantly during the time, and you do not want to bring it back as low as Xms, but keep it higher at a specific level (for example 1g). I believe this case is very rare, we can ignore it.</div><div>    </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> the difference between the current heap capacity and the current heap<br>
> usage is below MaxOverCommitted bytes. The MaxOverCommitted is a<br>
> dynamically user-defined variable. This check is ignored if<br>
> MaxOverCommitted is zero or below;<br>
> <br>
> <br>
> The previously mentioned concepts are illustrated in the figure<br>
> below:<br>
> <br>
> [...]<br>
> <br>
> The figure above depicts an application execution example where all<br>
> the aforementioned variables come into play. The default value for<br>
> all introduced variables (GCFrequency, MaxLoadGC, MaxOverCommitted,<br>
> and, MinCommitted) is zero. In other words, by default, there are no<br>
> periodic GCs.<br>
> <br>
> <br>
> With this these modifications, it is possible to periodically<br>
> eliminate unused committed memory in HotSpot. This is very important<br>
> for applications that do not trigger collections very frequently and<br>
> that might hold high amounts of unused committed memory. One example<br>
> are web servers, whose caches can timeout after some minutes and<br>
> whose memory might be underutilized (after the caches timeout) at<br>
> night when the amount of requests is very low.<br>
<br>
If I understood this paragraph correctly, the intent is to uncommit if<br>
the system is idle (has low load for a certain amount of time).<br>
<br>
Also, while it will become obvious with the patch, it will be<br>
interesting to see how that load is defined. One reason is basically<br>
that we support more systems than linux (the paper only mentions linux)<br>
and it may be useful to support more than that platform.<br></blockquote><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">The vast majority of use cases is in Linux I believe. </span>Load is defined via <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><i><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">os::loadavg</span></i></span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"> mentioned above. A feedback from an expert will be helpful <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">here</span>. </span></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">
<br>
I have one other question here, similar functionality could have been<br>
achieved by some external entity periodically polling the vm for heap<br>
size (a new jcmd or e.g. some MBean, or improving jmap or some other<br>
tool) and then forcing a system.gc from outside. Did you ever consider<br>
this?<br></blockquote><div>Doing it via tools like jcmd or MBean is possible, but has a hidden issue. Most likely it will be a cron based task. If you have hundreds / thousands containers on a node it's better to distribute the check time because if you launch the check at all containers together at same time you will get a huge spike on CPU. It's much more complex exercise.</div><div><br></div><div>An alternative option is javaagent which is automatically attached to each java process. Then the check time is distributed naturally as containers start at different time, plus it's less expensive on CPU because you do not launch any new process.</div><div>       </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The reason is that this idea uses some mechanisms (detecting load of<br>
system, lots of options) that may be better served and be more flexible<br>
if mostly implemented outside the VM.<br></blockquote><div>In Jelastic we do it in a similar way, as I described above. But it's too complex for a wider adoption, because it's not something easy to use / easy to enable (outside of Jelastic). So many java users will not be able to enjoy it. </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">
<br>
Having read Kirk P.'s concern about the mechanism to actually uncommit<br>
memory being too simplistic, I kind of agree. The alternative, to<br>
trigger a concurrent cycle plus multiple mixed collections (plus<br>
uncommit heap at the end of that mixed phase) is a bit harder to<br>
implement. I would certainly help you with that. :)<br></blockquote><div>I do believe the code / implementation can be improved. No religion about Full GC :). I would prefer to avoid it too if we can come with another solution at reasonable efforts.   </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also assuming that at that point the VM is idle, doing a full gc would<br>
not hurt the application.<br>
<br>
Also there is Michal's use case of periodically doing global reference<br>
processing to clean out weak references regularly. This seems to be a<br>
different use case, but would seem easy to do given that this change<br>
probably implements something like CMSTriggerInterval for G1.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Maybe there is some way to marry these two issues somehow.<br></blockquote><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Does<span> </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">CMSTriggerInterval</span><span> </span>influence the committed memory shrinking?  </div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> -Xmx Dynamic Limit Update <br>
> <br>
> To dynamically limit how large the committed memory (i.e. the heap<br>
> size) can grow, a new dynamically user-defined variable was<br>
> introduced: CurrentMaxHeapSize. This variable (defined in bytes)<br>
> limits how large the heap can be expanded. It can be set at launch<br>
> time and changed at runtime. Regardless of when it is defined, it<br>
> must always have a value equal or below to MaxHeapSize (Xmx - the<br>
> launch time option that limits how large the heap can grow). Unlike<br>
> MaxHeapSize, CurrentMaxHeapSize, can be dynamically changed at<br>
> runtime.<br>
> <br>
> For example dynamically set 1GB as the new Xmx limit<br>
> <br>
> jinfo -flag CurrentMaxHeapSize=1g <java_pid><br>
> <br>
> Setting CurrentMaxHeapSize at runtime will trigger a full collection<br>
> if the desired value is below the current heap size. After finishing<br>
> the full collection, a second test is done to verify if the desired<br>
> value is still above the heap size (note that a full collection will<br>
> try to shrink the heap as much as possible). If the value is still<br>
> below the current heap size, then an error is reported to the user.<br>
> Otherwise, the operation is successful. <br>
<br>
One alternative here could be to use a marking cycle + mixed gcs to<br>
reach that new CurrentMaxHeapSize again, which is again is a bit more<br>
complicated to achieve. I can help you implementing that if interested.<br>
<br>
In some cases you might even get away with just uncommitting empty<br>
regions and doing nothing else in response to this command.<br>
<br>
As Kirk mentioned, as another optimization, triggering a young gc could<br>
free enough regions too.<br></blockquote><div>Ok, I pass this question to <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Rodrigo </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Bruno and he has the required technical knowledge on the implementation</span>. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The limit imposed by the CurrentMaxHeapSize can be disabled if the<br>
> variable is unset at launch time or if it is set to zero or below at<br>
> runtime.<br>
> <br>
> This feature is important to cope with changes in workload demands<br>
> and to avoid having to restart JVMs to cope with workload changes.<br>
<br>
I have only one question about this here at this time: is this<br>
CurrentMaxHeapSize a new "hard" heap size (causing OOME in the worst<br>
case), or could this be temporarily exceeded and any excess memory<br>
given back asap?<br></blockquote><div>For now it's the new hard limit.  </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Would it be useful to have G1 more slowly adapt to that that new goal<br>
size?<br></blockquote><div>We may have a problem here, as <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">CurrentMaxHeapSize will be usually bound to container/VM limits. If you resize container/VM you need to get back a clear answer - yes or no (not possible to decrease), then you can continue or cancel the resizing action. Adding async behavior can complicate the logic and code. I would prefer to keep it simple at the first implementation. We can adjust it later based on the feedback from more use cases.      </span></div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As you can see I am pretty interested in the changes... :)<br></blockquote><div>Good! Just to clarify one more time that at Jelastic we are fine already. The ultimate goal is to evangelize elasticity of JVM. The cloud world is more dynamic now than it was in the last.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So overall, if you agree, I will open two JEPs in our bug tracker and<br>
we can start discussing and filling out the details.<br></blockquote><div>Yep, let's move on! Thank you!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
  Thomas<br>
<br>
[0] <a href="http://openjdk.java.net/jeps/2" rel="noreferrer" target="_blank">http://openjdk.java.net/jeps/2</a><br>
[1] <a href="https://wiki.openjdk.java.net/display/csr/Main" rel="noreferrer" target="_blank">https://wiki.openjdk.java.net/<wbr>display/csr/Main</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-2469209081482962941m_4968739607699058569gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:12.8px"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:"Times New Roman""><span style="font-family:Calibri,sans-serif;font-size:15px">Ruslan</span><br style="font-family:Calibri,sans-serif;font-size:15px"><span style="font-family:Calibri,sans-serif;font-size:15px">CEO @ </span><span style="font-family:Calibri,sans-serif;font-size:15px"><a href="https://jelastic.com/" style="color:rgb(17,85,204)" target="_blank">Jelastic</a></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>