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

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:

• restart the JVM whenever the application needs more or less Java heap 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.
• grant the JVM a large maximum Java heap memory limit. This will eventually lead to resource wastage as the JVM does not very eagerly release Java heap memory by design.

Testing

Section 5.4 of the paper available at https://dl.acm.org/doi/abs/10.1145/3210563.3210567 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.