RFR: 8222145: Add -XX:SoftMaxHeapSize flag

[Thomas Schatzl]

Hi Ruslan,

On Wed, 2019-04-10 at 18:53 +0200, Ruslan Synytsky wrote:
> So happy to get this long-awaited improvement! 
> 
> There are additional materials related to the same issue: JEP draft:
> Dynamic Max Memory Limit
> https://openjdk.java.net/jeps/8204088
> https://bugs.openjdk.java.net/browse/JDK-8204088

The most recent webrev is at 
http://cr.openjdk.java.net/~tschatzl/jelastic/cmx/ (I will call it
CurrentMaxHeapSize approach in the following); note that that change
implements something slightly different: it modifies the current *hard*
max heap size. Which means that the heap size, once successfully set,
will not go over this value, and if the application does, throw an
OOME.

The -XX:SoftMaxHeapSize value, is only a goal for the collector to
start reclaiming memory only. It may still, at will, use more memory
(up to regular MaxHeapSize).
Of course, that overshoot will depend on the collector.

The effect is similar, but not exactly that in border cases; if there
were somebody to work on this (maybe Lin from the other sub-thread or
you?), so would something like that an acceptable solution for you too?

I believe for this to work (and this is mostly a guess), it may be
sufficient to call G1IHOPControl::update_target_occupancy() with the
new SoftMaxHeapSize flag at certain places(*) instead of modifying the
actual maximum heap sizes like in the other attempt.
The heap sizing algorithm should then automatically do the right thing,
particularly in combination with JEP 346.

(*) Being very conservative, only at (induced) safepoints; however
since this would only change the timing when and how gcs are triggered,
there should not be too much harm otherwise.

This is different to changing the current (hard) max heap size; more
care may needs to be taken (i.e. more analysis) there, that's why it
has not been picked up by the Oracle gc team at this time.

There is at least one, if not more, ways of misusing the
CurrentMaxHeapSize approach that comes to my mind (totally random):
what would be the expectation of the user if he updated
CurrentMaxHeapSize in an OOME handler caused by reaching
CurrentMaxHeapSize?

In addition to that, some details need to be worked out what should
happen when, e.g. should memory automatically be uncommitted asap, or
some time later? Unfortunately JDK-8222145 also does not give an
answer.

> Rodrigo Bruno implemented a patch for G1 already. The algorithm is
> described at the research 
> http://ranger.uta.edu/~jrao/papers/ISMM18.pdf (flag
> name CurrentMaxMemory).  
> 
> Should we join the efforts and deliver it together? 

We would be happy for contributions :) - unfortunately we at Oracle at
this time do not have the time for significant work on it similar to
JEP 346 right now.

Thanks,
  Thomas