JEP draft: Dynamic Max Memory Limit

AuthorsRodrigo Bruno, Ruslan Synytsky
OwnerThomas Schatzl
TypeFeature
ScopeImplementation
StatusDraft
Componenthotspot / gc
EffortS
DurationS
Created2018/05/30 14:22
Updated2018/06/08 12:45
Issue8204088

Summary

This JEP intends to allow the user to increase and/or decrease of the amount of Java heap memory available to the application at runtime.

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.

Success Metrics

The implementation should allow a user to increase and/or decrease the amount of Java heap memory that can be used by the Java application. This operation 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. The user should be informed 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 in a timely fashion. 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 Java heap at 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

There are two alternatives:

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 Java heap memory limit (-Xmx) leads to a very small increase in the memory footprint. For example, increasing -Xmx by 32GB increases the footprint by 31MB.