JEP draft: Dynamic Max Memory Limit

AuthorsRodrigo Bruno, Ruslan Synytsky
OwnerThomas Schatzl
Componenthotspot / gc
Created2018/05/30 14:22
Updated2018/06/22 11:44


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.


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.


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.


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.


There are two alternatives:


Section 5.4 of the paper available at 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.