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

[Rodrigo Bruno]

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/~rb
runo/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/20180530/498b03e2/attachment.htm>