RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics

[Liang Mao]

Hi Thomas,

As we previously discussed, I use the concurrent heap uncommit/commit mechanism to implement the
 SoftMaxHeapSize for G1. It is also for the further implementation of G1ElasticHeap for ergonomic
change of heap size. In the previous 8u implementation, we had some limitations which are all
removed now in this patch. The concurrent uncommit/commit can also work with some senarios for
 immediate heap expansion.

Here is the webrev link:
http://cr.openjdk.java.net/~luchsh/8236073.webrev/

We still have some questions.
1. Does the SoftMaxHeapSize limitation need to consider the GC time ratio as in
expand_heap_after_young_collection? Now we haven't put the logic in yet.
2. The concurrent uncommit/commit can only work for G1RegionsLargerThanCommitSizeMapper but not
G1RegionsSmallerThanCommitSizeMapper which might need some locks to ensure the multi-thread
 synchronization issue( heap may expand immediately). I think bringing the lock synchronization
may not be worthy for the little gain. Another idea is can we just not uncommit the pages of
auxiliary data if in G1RegionsSmallerThanCommitSizeMapper? Heap regions should not be 
G1RegionsSmallerThanCommitSizeMapper most of time I guess...

Looking forward to your advice:)

Thanks,
Liang


------------------------------------------------------------------
From:MAO, Liang <maoliang.ml at alibaba-inc.com>
Send Time:2019 Oct. 14 (Mon.) 11:52
To:Thomas Schatzl <thomas.schatzl at oracle.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: G1 patch of elastic Java heap

Hi Thomas,

Thank you for the recognition:) Since we both agree on some clear specific points,
 I will try to extract them from current implementation and create a patch in OpenJDK
upstream branch so we can continue discussion on the code level.

Thanks,
Liang





------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2019 Oct. 12 (Sat.) 23:00
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: G1 patch of elastic Java heap

Hi,

On Sat, 2019-10-12 at 19:51 +0800, Liang Mao wrote:
> Hi Thomas,
> 
> The manual generation limit can be put aside currently since we know
> it might not be so general for a GC. We can focus on how to change
> heap size and return memory in runtime first. 
> 
> GCTimeRatio is a good metric to measure the health of a Java
> application and I have considered to use that. But finally I chose
> a simple way just like the periodic old GC. Guarantee a long 
> enough young GC interval is an alternative way to make sure the
> GCTimeRatio at a heathy state. 
> I'm absolutely ok to use GCTimeRatio instead of the fixed young GC
> interval. This part is same to ZGC or Shenandoah for how to balance
> the desired memory size and GC frequency. I'm open to  any good
> solution and we are already in the same page for this issue
> I think:)

+1

> A big difference of our implementation is evaluating heap resizing in
> any young GC instead of a concurrent gc cycle which I think is
> swifter and more immmediate. The concurrent map/unmap 
> mechanism gets rid of the additional pause time. My thought is the
> heap shrink/expand can be all determined in young GC pause and
> performed in concurrent thread which could exclude the 
> considerable time cost by OS interface. Most of our Java users are
> intolerant to those pause pikes caused by page fault which can be up
> to seconds. And we also found the issue of time cost by map/unmap in
> ZGC.
>
> A direct advantage of the young GC resizing and concurrent memory
> free machanism is for implementing SoftMaxHeapSize. The heap size can
> be changed after last mixed GC. The young GC won't have longer
> pause and the memory can be freed concurrently without side effect.

Agree and agree. Both evaluating and giving back memory at any gc
sounds nice, and doing that without incurring the costs in the pause is
even better :)

Thanks,
  Thomas