Status of JEP-8204088/JDK-8236073

[Thomas Schatzl]

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.

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

+1

Thomas