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

Sun Jun 3 15:44:18 UTC 2018

Hi Thomas,

further suggestions and rearrangements on this JEP draft follow below:

*Goals:*

The goal of this JEP is to allow the increase and/or decrease of the amount
of memory available to the application.

*Non-Goals:*

It is not a goal to change current heap sizing algorithms.
It is not a goal to dynamically change the maximum heap size limit as this
would require a lot of engineering
effort (maybe in the future).

*Success Metrics:*

The implementation should allow a user to increase and/or reduce the amount
of memory that can be used by the
application. This must be possible at any point during the execution of an
application. If it is not possible to
increase or decrease the amount of memory available to the application, the
operation should fail and the user
must be aware of the result of the operation.

*Motivation:*

Elasticity is the key feature of the cloud computing. It enables to scale
resources according to application workloads
timely. Now we live in the container era. Containers can be scaled
vertically on the fly without downtime. This provides
much better elasticity and density compared to VMs. However, JVM-based
applications are not fully container-ready.
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
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.

*Alternatives:*

There are two alternatives:
1 - restart a JVM whenever the application needs more or less memory. This
will adapt the memory usage of the JVM
to the application needs at the cost of downtime (which can be prohibitive
for many applications).
2 - grant a large maximum memory limit. This will eventually lead to
resource wastage.

*Testing:*

Section 5.4 of the paper available at
http://www.gsd.inesc-id.pt/~rbruno/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.

Best,
rodrigo

2018-05-30 21:44 GMT+02:00 Thomas Schatzl <thomas.schatzl at oracle.com>:

> 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.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180603/1bc04b48/attachment.htm>