Status of JEP-8204088/JDK-8236073

[Ruslan Synytsky]

Hi Man, thank you for your feedback. It is clear and highly appreciated. I
love the SoftMaxHeapSize idea and the use cases it serves. It's a great
step forward. Now we can learn, improve, fix and get it better every new
release. At the same time, should we really compare CurrentMaxHeapSize (or
HardMaxHeapSize) vs SoftMaxHeapSize and try to replace one by another?
There are different use cases. One of them just got my attention recently -
restoring JVM runtimes from previosuly saved state
https://mail.openjdk.java.net/pipermail/discuss/2021-July/005890.html. Can
we start from an experimental option for G1 or something that will unlock
us to put more effort behind it?
Thanks
--
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS


On Tue, 27 Jul 2021 at 02:39, Man Cao <manc at google.com> wrote:

> Hi all,
>
> I added the "g1-heap-resizing" label to the issues that have been brought
> up in the thread:
> https://bugs.openjdk.java.net/issues/?jql=labels+%3D+g1-heap-resizing.
> We agree that most of these issues should be resolved first, before
> further working on SoftMaxHeapSize or developing an external component to
> automatically set GCTimeRatio/GCCpuPercentage at runtime.
>
> Regarding CurrentMaxHeapSize, it is tracked in
> https://bugs.openjdk.java.net/browse/JDK-8204088. It seems more
> independent of other g1-heap-resizing issues, so perhaps it could be
> implemented earlier. On the other hand, once most of the g1-heap-resizing
> issues are fixed, SoftMaxHeapSize should behave better. One main goal of
> those g1-heap-resizing issues is to fix the problem that "G1 expands the
> heap too aggressively".
>
> I agree that CurrentMaxHeapSize can address several problems that cannot
> be solved by tuning SoftMaxHeapSize and/or GCTimeRatio/GCCpuPercentage.
> However, it may introduce other issues and does not satisfy all of our
> requirements. In particular:
> - In our experience, having a tight Xmx is prone to GC thrashing, which
> could make servers unresponsive and wasting CPU resources, and is worse
> than getting killed by a container manager due to running out of container
> RAM (because a killed process can be restarted easily). I suspect using
> CurrentMaxHeapSize instead of SoftMaxHeapSize will increase the chance of
> GC thrashing, when it is better to let the process run out of container RAM
> limit and get killed and restarted.
>
> - We found that turning off CompressedOops could waste 30%-40%
> heap memory. This means many of our servers are better off keeping Xmx
> below 32G. Thus, many of our servers cannot directly use the strategy of
> setting Xmx to the maximum memory available, then dynamically adjust
> CurrentMaxHeapSize. Admittedly, this problem exists for both
> CurrentMaxHeapSize or SoftMaxHeapSize. We will probably need to develop a
> separate strategy to determine when to make Xmx go above 32G. It is also
> possible to set -XX:ObjectAlignmentInBytes=16, which can then use
> CompressedOops up to 64G of Xmx.
>
> We are definitely happy to experiment and compare automatically setting
> CurrentMaxHeapSize vs SoftMaxHeapSize. Again, SoftMaxHeapSize is not ready
> until most g1-heap-resizing issues are fixed.
>
> -Man
>