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

[Thomas Schatzl]

Hi Rodrigo,

  sorry for the late reply, this email somehow got unanswered...

On Sun, 2018-06-03 at 17:44 +0200, Rodrigo Bruno wrote:
> 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/~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.


I updated the text accordingly; I did some minor changes so that
"memory" was always called out as Java heap memory as opposed to memory
used for VM internal data structures.

Thanks,
  Thomas