<div dir="ltr">Hi Thomas,<div><br></div><div>further suggestions and rearrangements on this JEP draft follow below:</div><div><br></div><div><b>Goals:</b></div><div><br></div><div>The goal of this JEP is to a<span style="color:rgb(51,51,51);font-family:Arial,sans-serif">llow the increase and/or decrease of the amount of memory available to the application.</span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"><b>Non-Goals:</b></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">It is not a goal to change current heap sizing algorithms.</span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">It is not a goal to dynamically change the maximum heap size limit as this would require a lot of engineering</span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">effort (maybe in the future).</span></div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"><b>Success Metrics:</b></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">The implementation should allow a user to increase and/or reduce the amount of memory that can be used by the</span></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">application. This must be possible at any point during the execution of an application. If it is not possible to</span></div><div><font color="#333333" face="Arial, sans-serif">increase or decrease the amount of memory available to the application, the operation should fail and the user</font></div><div><font color="#333333" face="Arial, sans-serif">must be aware of the result of the operation.</font></div><div><font color="#333333" face="Arial, sans-serif"><br></font></div><div><font color="#333333" face="Arial, sans-serif"><b>Motivation:</b></font></div><div><font color="#333333" face="Arial, sans-serif"><br></font></div><div><span id="gmail-m_-3812440945132564021gmail-docs-internal-guid-fecb731d-c646-5f73-ab97-771994b1572e"><span style="color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">Elasticity is the key feature of the cloud computing. It enables to scale resources according to application workloads</font></span></span></div><div><span><span style="color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">timely. Now we live in the container era. Containers can be scaled vertically on the fly without downtime. This provides</font></span></span></div><div><span><span style="color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">much better elasticity and density compared to VMs. However, JVM-based applications are not fully container-ready. </font></span></span></div><div><span><span style="color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">One of the current issues is the fact that it is not possible to increase the size of JVM Heap in runtime. If your production</font></span></span></div><div><span><span style="color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">application has an unpredictable traffic spike, the only one way to increase the Heap size is to restart the JVM with a </font></span></span></div><div><span><span style="color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><font face="arial, helvetica, sans-serif">new Xmx parameter. </font></span></span><font color="#333333" face="Arial, sans-serif"><br></font></div><div><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"><br></span></div><div class="gmail_extra"><b>Alternatives:</b></div><div class="gmail_extra"><br></div><div class="gmail_extra">There are two alternatives:</div><div class="gmail_extra">1 - restart a JVM whenever the application needs more or less memory. This will adapt the memory usage of the JVM</div><div class="gmail_extra">to the application needs at the cost of downtime (which can be prohibitive for many applications).</div><div class="gmail_extra">2 - grant a large maximum memory limit. This will eventually lead to resource wastage.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>Testing:</b></div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">Section 5.4 of the paper available at </span><a href="http://www.gsd.inesc-id.pt/~rbruno/publications/rbruno-ismm18.pdf" style="color:rgb(59,115,175);text-decoration:none;font-family:Arial,sans-serif">http://www.gsd.inesc-id.pt/~rbruno/publications/rbruno-ismm18.pdf</a><span style="color:rgb(51,51,51);font-family:Arial,sans-serif"> shows that having </span></div><div class="gmail_extra"><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">a very high maxium memory limit (-Xmx) leads to a very small increase in the memory footprint. For example, increasing</span></div><div class="gmail_extra"><span style="color:rgb(51,51,51);font-family:Arial,sans-serif">-Xmx by 32GB increases the footprint by 31MB.</span><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Best,</div><div class="gmail_extra">rodrigo</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">2018-05-30 21:44 GMT+02:00 Thomas Schatzl <span dir="ltr"><<a href="mailto:thomas.schatzl@oracle.com" target="_blank">thomas.schatzl@oracle.com</a>></span>:<br><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>
fyi, I filed <a href="https://bugs.openjdk.java.net/browse/JDK-8204088" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/<wbr>browse/JDK-8204088</a> and put<br>
the text we have in there.<br>
<br>
Thanks,<br>
Thomas<br>
<div class="gmail-m_-3812440945132564021HOEnZb"><div class="gmail-m_-3812440945132564021h5"><br>
On Wed, 2018-05-30 at 11:43 +0100, Rodrigo Bruno wrote:<br>
> Summary<br>
> -------<br>
> <br>
> // REQUIRED -- Provide a short summary of the proposal, at most one<br>
> or two<br>
> // sentences. This summary will be rolled up into feature lists,<br>
> JSRs, and<br>
> // other documents, so please take the time to make it short and<br>
> sweet.<br>
> <br>
> This JEP allows the JVM to dynamically adjust the maximum available<br>
> memory to<br>
> the application. It provides a dynamic limit for the maximum memory<br>
> limit as opposed to<br>
> the current static limit (-Xmx).<br>
> <br>
> Goals<br>
> -----<br>
> <br>
> // What are the goals of this proposal? Omit this section if you<br>
> have<br>
> // nothing to say beyond what's already in the summary.<br>
> <br>
> Increase and decrease the heap size on demand.<br>
> <br>
> Non-Goals<br>
> ---------<br>
> <br>
> // Describe any goals you wish to identify specifically as being out<br>
> of<br>
> // scope for this proposal.<br>
> <br>
> Success Metrics<br>
> ---------------<br>
> <br>
> // If the success of this work can be gauged by specific numerical<br>
> // metrics and associated goals then describe them here.<br>
> <br>
> Section 5.4 of the paper available at <a href="http://www.gsd.inesc-id.pt/~rbr" rel="noreferrer" target="_blank">http://www.gsd.inesc-id.pt/~rb<wbr>r</a><br>
> uno/publications/rbruno-ismm18<wbr>.pdf<br>
> shows that having a very high maxium memory limit (-Xmx) leads to a<br>
> very small increase in the<br>
> memory footprint. For example, increasing -Xmx by 32GB increases the<br>
> footprint by 31MB.<br>
> <br>
> <br>
> Motivation<br>
> ----------<br>
> <br>
> // Why should this work be done? What are its benefits? Who's<br>
> asking<br>
> // for it? How does it compare to the competition, if any?<br>
> <br>
> Currently, it is not possible to increase the size of JVM Heap in<br>
> runtime. <br>
> If your production application has an unpredictable traffic spike,<br>
> the only one way to increase the Heap size is to restart the JVM with<br>
> a new Xmx parameter. <br>
> <br>
> Description<br>
> -----------<br>
> <br>
> // REQUIRED -- Describe the enhancement in detail: Both what it is<br>
> and,<br>
> // to the extent understood, how you intend to implement it. <br>
> Summarize,<br>
> // at a high level, all of the interfaces you expect to modify or<br>
> extend,<br>
> // including Java APIs, command-line switches, library/JVM<br>
> interfaces,<br>
> // and file formats. Explain how failures in applications using this<br>
> // enhancement will be diagnosed, both during development and in<br>
> // production. Describe any open design issues.<br>
> //<br>
> // This section will evolve over time as the work progresses,<br>
> ultimately<br>
> // becoming the authoritative high-level description of the end<br>
> result.<br>
> // Include hyperlinks to additional documents as required.<br>
> <br>
> To dynamically limit how large the committed memory (i.e. the heap<br>
> size) can grow, a new dynamically user-defined variable is<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>
> The expected usage is to setup the JVM with a very conservative Xmx<br>
> value (which is shown to have a very small impact on memory<br>
> footprint) and <br>
> then control how large the heap is using the CurrentMaxHeapSize<br>
> dynamic limit.<br>
> <br>
> <br>
> Alternatives<br>
> ------------<br>
> <br>
> // Did you consider any alternative approaches or technologies? If<br>
> so<br>
> // then please describe them here and explain why they were not<br>
> chosen.<br>
> <br>
> Testing<br>
> -------<br>
> <br>
> // What kinds of test development and execution will be required in<br>
> order<br>
> // to validate this enhancement, beyond the usual mandatory unit<br>
> tests?<br>
> // Be sure to list any special platform or hardware requirements.<br>
> <br>
> Risks and Assumptions<br>
> ---------------------<br>
> <br>
> // Describe any risks or assumptions that must be considered along<br>
> with<br>
> // this proposal. Could any plausible events derail this work, or<br>
> even<br>
> // render it unnecessary? If you have mitigation plans for the known<br>
> // risks then please describe them.<br>
> <br>
> Dependencies<br>
> -----------<br>
> <br>
> // Describe all dependencies that this JEP has on other JEPs, JBS<br>
> issues,<br>
> // components, products, or anything else. Dependencies upon JEPs or<br>
> JBS<br>
> // issues should also be recorded as links in the JEP issue itself.<br>
> //<br>
> // Describe any JEPs that depend upon this JEP, and likewise make<br>
> sure<br>
> // they are linked to this issue in JBS.<br>
> <br>
<br>
</div></div></blockquote></div><br></div></div>