RFR: 8222145: Add -XX:SoftMaxHeapSize flag

[臧琳]

This is so interesting, I am trying to implement the idea of extend maxheapsize at a ratio at
runtime based on G1，which could more or less help to avoid the OOM/fullGC cause online service hang
in my BigData scenario.
It seems the design is similar with the SoftMaxHeapSize，So maybe I could help to contribute in G1 part of this.

BRs,
Lin

在 2019年4月10日，下午11:57，Per Liden <per.liden at oracle.com<mailto:per.liden at oracle.com>> 写道：

Thanks for reviewing, Thomas!

/Per

On 04/10/2019 05:52 PM, Thomas Schatzl wrote:
Hi,
On Wed, 2019-04-10 at 14:06 +0200, Per Liden wrote:
Introduce a manageable SoftMaxHeapSize flag. When set, the GC should
strive to not grow heap size beyond the specified size. But as the
flag name suggests, this is a soft limit. In other words, the GC is
allowed to grow the heap size beyond SoftMaxHeapSize if needed.

There are a few different use cases where this flag could be useful.
For example, when you want to keep the heap footprint down, while
retaining the capability to deal with a temporary increase in heap
space requirement. Or when you want to play it safe, with lots of
margin, to increase confidence that you will not run into an
allocation stall because of an unforeseen increase in allocation
rate.

The SoftMaxHeapSize should not be allowed to be set to a value
smaller than min heap size (-Xms) or greater than max heap size (-
Xmx). When not set on the command-line, this flag should default to
the max heap size.

Bug: https://bugs.openjdk.java.net/browse/JDK-8222145
CSR: https://bugs.openjdk.java.net/browse/JDK-8222181
Webrev: http://cr.openjdk.java.net/~pliden/8222145/webrev.1

  looks good to me.
Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190411/d3da130c/attachment.htm>