JEP draft: Dynamic Max Memory Limit [Was. Re: Elastic JVM improvements]

[Thomas Schatzl]

Hi,

  fyi, I filed https://bugs.openjdk.java.net/browse/JDK-8204088 and put
the text we have in there.

Thanks,
  Thomas

On Wed, 2018-05-30 at 11:43 +0100, Rodrigo Bruno wrote:
> Summary
> -------
> 
> // REQUIRED -- Provide a short summary of the proposal, at most one
> or two
> // sentences.  This summary will be rolled up into feature lists,
> JSRs, and
> // other documents, so please take the time to make it short and
> sweet.
> 
> This JEP allows the JVM to dynamically adjust the maximum available
> memory to
> the application. It provides a dynamic limit for the maximum memory
> limit as opposed to
> the current static limit (-Xmx).
> 
> Goals
> -----
> 
> // What are the goals of this proposal?  Omit this section if you
> have
> // nothing to say beyond what's already in the summary.
> 
> Increase and decrease the heap size on demand.
> 
> Non-Goals
> ---------
> 
> // Describe any goals you wish to identify specifically as being out
> of
> // scope for this proposal.
> 
> Success Metrics
> ---------------
> 
> // If the success of this work can be gauged by specific numerical
> // metrics and associated goals then describe them here.
> 
> Section 5.4 of the paper available at http://www.gsd.inesc-id.pt/~rbr
> uno/publications/rbruno-ismm18.pdf
> shows that having a very high maxium memory limit (-Xmx) leads to a
> very small increase in the
> memory footprint. For example, increasing -Xmx by 32GB increases the
> footprint by 31MB.
> 
> 
> Motivation
> ----------
> 
> // Why should this work be done?  What are its benefits?  Who's
> asking
> // for it?  How does it compare to the competition, if any?
> 
> Currently, it is not possible to increase the size of JVM Heap in
> runtime. 
> If your production application has an unpredictable traffic spike,
> the only one way to increase the Heap size is to restart the JVM with
> a new Xmx parameter. 
> 
> Description
> -----------
> 
> // REQUIRED -- Describe the enhancement in detail: Both what it is
> and,
> // to the extent understood, how you intend to implement it. 
> Summarize,
> // at a high level, all of the interfaces you expect to modify or
> extend,
> // including Java APIs, command-line switches, library/JVM
> interfaces,
> // and file formats.  Explain how failures in applications using this
> // enhancement will be diagnosed, both during development and in
> // production.  Describe any open design issues.
> //
> // This section will evolve over time as the work progresses,
> ultimately
> // becoming the authoritative high-level description of the end
> result.
> // Include hyperlinks to additional documents as required.
> 
> To dynamically limit how large the committed memory (i.e. the heap
> size) can grow, a new dynamically user-defined variable is
> introduced: CurrentMaxHeapSize. This variable (defined in bytes)
> limits how large the heap can be expanded. It can be set at launch
> time and changed at runtime. Regardless of when it is defined, it
> must always have a value equal or below to MaxHeapSize (Xmx - the
> launch time option that limits how large the heap can grow). Unlike
> MaxHeapSize, CurrentMaxHeapSize, can be dynamically changed at
> runtime.
> 
> The expected usage is to setup the JVM with a very conservative Xmx
> value (which is shown to have a very small impact on memory
> footprint) and 
> then control how large the heap is using the CurrentMaxHeapSize
> dynamic limit.
> 
> 
> Alternatives
> ------------
> 
> // Did you consider any alternative approaches or technologies?  If
> so
> // then please describe them here and explain why they were not
> chosen.
> 
> Testing
> -------
> 
> // What kinds of test development and execution will be required in
> order
> // to validate this enhancement, beyond the usual mandatory unit
> tests?
> // Be sure to list any special platform or hardware requirements.
> 
> Risks and Assumptions
> ---------------------
> 
> // Describe any risks or assumptions that must be considered along
> with
> // this proposal.  Could any plausible events derail this work, or
> even
> // render it unnecessary?  If you have mitigation plans for the known
> // risks then please describe them.
> 
> Dependencies
> -----------
> 
> // Describe all dependencies that this JEP has on other JEPs, JBS
> issues,
> // components, products, or anything else.  Dependencies upon JEPs or
> JBS
> // issues should also be recorded as links in the JEP issue itself.
> //
> // Describe any JEPs that depend upon this JEP, and likewise make
> sure
> // they are linked to this issue in JBS.
>