hotspot-gc-dev Digest, Vol 168, Issue 38

[Man Cao]

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