Status of JEP-8204088/JDK-8236073

[Rodrigo Bruno]

Hi Thomas, Hi Man,

On Mon, 2 Aug 2021 at 16:49, Thomas Schatzl <thomas.schatzl at oracle.com>
wrote:

> Hi Man,
>
> On 27.07.21 01:39, Man Cao 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
> > <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.
>
> Thanks.
>
> >
> > Regarding CurrentMaxHeapSize, it is tracked in
> > https://bugs.openjdk.java.net/browse/JDK-8204088
> > <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".
>
> Fwiw, these two are fairly independent issues, and the main problem with
> the proposed CurrentMaxHeapSize patch has been that the change is not
> atomic in the sense that the changes simply modify the global heap size
> variable without regard whether and when it is accessed. That may result
> in fairly nasty races as different components of the GC may then have a
> different notion of what the current max heap size actually is at the
> moment.
>

That is true. However, we could easily do the update to CurrentMaxHeapSize
inside a VMOperation to ensure an atomic change. This is not in the current
patch but it is probably a simple change. Right?


>
> >
> > 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.
>

Agreed. If CurrentMaxHeapSize is used to decrease the size of the heap,
then trashing could be an issue. However, it also gives you the option to
increase the size of the heap if the current heap is leading to trashing. I
understand that in some services it might be easier to restart the service.
This is not the case for example in user applications where state might be
lost after a restart.


> >
> > - 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.
>
> +1
>
+1

>
> Thomas
>


-- 
rodrigo-bruno.github.io