RFR: 8222145: Add -XX:SoftMaxHeapSize flag

[Thomas Schatzl]

Hi,

On Thu, 2019-04-11 at 14:02 +0200, Rodrigo Bruno wrote:
> Hello all,
> 
> 
> [...]
> The CurrentMaxHeapSize idea is to allow the customer to inform the
> application of how much memory it should use at most. This is
> necessary because many applications will read the max heap size and 
> will just use all the available memory for example, to cache data. 
> With this patch, we give the application an opportunity to read the 
> new max heap size, which will return the CurrentMaxHeapSize 
> containing the value that the user wants.
> 
> The difference here from using the update_target_occupancy (besides
> potential overshooting) is that this is not visible to the 
> application (please correct me if this not true). In other words, if
> I change the threshold at runtime, can the application see the
> change?

I only think that the current implementation of the Dynamic Max Memory
Limit JEP as known to me does not implement the SoftMaxHeapSize
functionality. :)

The remainder of this email are just random thoughts.

As for observability, the CurrentMaxHeapSize implementation has the
advantage, that by changing the real internal max heap size, all
derived values (e.g. generation sizes) automatically follow, and so the
values of the application observable values (I think you were referring
to e.g. MemoryMXBeans?).

I would consider allowing memory usage overshooting the more graceful
and more flexible useful approach for customers, but triggering OOME,
effectively killing the VM is probably a valid use case too (i.e. what
happens if the CurrentMaxHeapSize has not been set lenient enough?)

By only triggering a concurrent cycle (if needed) in a potential
SoftMaxHeapSize as outlined by me previously (there may be others,
better ones!), at worst you would get at most continuous concurrent
cycles. Compared to a CurrentMaxHeapSize implementation, it does need
some additional changes that you get "for free" otherwise, e.g. the
young gen sizing probably needs to be adapted a bit, and the contents
of the values returned to the application via the mentioned
MemoryMXBeans.

I guess that in terms of code changes, both will be in the same
ballpark.

Finally I also think that there might be a few cases that need to be
better understood in the CurrentMaxHeapSize implementation, e.g. if you
set a CurrentMaxHeapSize lower than (or close to) current usage -
probably it will do a full gc, which might not be what you want (if you
do, well, you just set SoftMaxHeapSize manually, so you could as well
manually trigger a full gc at the same time). And, this
CurrentMaxHeapSize implementation probably suffers from issues with
different threads observing different current max heap sizes, as the
current max heap size is used directly for allocation thresholds (not
really guaranteeing the new max heap size after all).

> Probably a good solution is somewhere in the middle, where we can let
> the application know the current limit and maybe be a bit more
> aggressive when we get closer to the threshold (current max heap
> size). 
> 
> What do you think?

As changing the "real" max heap size in the GC it directly influences
the target threshold, so the impact to the application in terms of
number of gcs and the performance impact would be exactly the same.

The existing CurrentMaxHeapSize solution could certainly be adapted too
to be more flexible to implement both SoftMaxHeapSize and
CurrentMaxHeapSize. I.e. I can see uses for both, just that
SoftMaxHeapSize seems to be the more flexible (and desirable) overall.

The community probably open to both as long as they are useful on their
own, and well implemented :)

Summarizing I was merely noting that the implementation there is for
the Dynamic Max Memory Limit JEP implements something slightly
different to the requirements than SoftMaxHeapSize - and that Oracle
can not take the lead for such an implementation at this time.

Thanks,
  Thomas