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

[Thomas Schatzl]

Hi Liang, Stefan,

   let me summarize the current point of discussion a bit, because I 
believe there are some subtle misunderstandings.

On 18.02.20 13:48, Liang Mao wrote:
> Hi Stefan,
> 
> I don't think we need an earlier shrink if we are trying to do it just a
> bit later after mixed GCs. For the concurrent uncommit, I already had
> a patch http://cr.openjdk.java.net/~luchsh/8236073.webrev/

That's fine, and Stefan agrees too. Let's keep these two separate. These 
changes can even be pushed in a single push if necessary, but I do not 
think so.

Thanks a lot for your really quick responses, we really appreciate your 
effort.

 > But need spend some time to refine it according to Thomas' comments.

Please give us a day to look at the current change (.4) in more detail 
and allow us to respond in a more coherent fashion too :)

We also would like to do some short tests which take some time to 
suggest (hopefully) the best opportunities where/what to improve.


>     ------------------------------------------------------------------
>     From:Stefan Johansson <stefan.johansson at oracle.com>
>     Send Time:2020 Feb. 18 (Tue.) 17:17
>     To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>
>     Cc:hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
>     Subject:Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics
> 
>     Hi Liang,
> 
>     I’ve also recently been looking at shrinking the heap after the Mixed collections. I totally agree that we should try to uncommit at this point, since the usage should be the lowest. I’m however not convinced that we should only uncommit once. My findings the last time, and what I’m seeing with your patch is some very long pauses when doing the uncommit. To try to avoid those I started looking at doing the uncommit concurrently, but didn’t find enough time to really dig into the details around that. An other thing to investigate would be the suggestion in:
>     https://bugs.openjdk.java.net/browse/JDK-8210709
> 
>     My main point is that we need to ensure that uncommitting memory don’t come with a to high cost.
> 
>     Thanks,
>     Stefan
> 
> 
>      > 18 feb. 2020 kl. 08:27 skrev Liang Mao <maoliang.ml at alibaba-inc.com>:
>      >
>      >
>      > Hi Stefan,
>      >
>      > Thank you for your comments!
>      >
>      > Based on previous discussion, the reasons are as below:
>      > 1) For the expansion after cm, I think we have the agreement that
>      > original MinHeapFreeRatio might be too large and predicting the necessary
>      > size from adaptive IHOP for expansion sounds reasonable and specjbb2015
>      > have the good result.

(Being aware that I am ignoring above comment about premature comments 
two seconds later, but no new comments here, only an attempt on 
clarification :( )

I think Stefan wanted to ask why the heuristic _expands_ at Cleanup at 
all. There does not seem to be need to do that at that time given that 
at the end of mixed gc we resize the heap "optimally" anyway.

Expansion at Cleanup (or Remark) seems to be not desired, so not doing 
anything might be the best option here. At worst G1 will intermittently 
expand automatically at one of the GCs between Cleanup pause and last 
mixed gc.

There may be issues with that idea.


>      > 2) About when to shrink the heap, I think it's a better spot after
>      > mixed collections. From my observation, the heap use is still at nearly
>      > peak after remark for most of cases like Alibaba workloads and specjbb2015.
>      > There could be some senario which contains a lot of humongous regions that
>      > remark will cleanup considerable regions. But why don't we decide to shrink
>      > the heap size when most of garbages have been cleaned after mixed GCs. We
>      > don't need to shrink twice in an old gc cycle. The MaxHeapFreeRatio 70 to
>      > keep heap capacity with 30% live objects make sence and is unified with full
>      > gc logic. If we only shrink the heap at remark, the maximum desired capacity
>      > could be 100/30 times of peak heap usage which is obviously not efficient.
>      >

I think Stefan suggests to shrink both at Remark (but do not expand 
then), particularly if we happen to really have a lot of free data now. 
Then refine that result at the last mixed gc. I.e. not let the user wait 
that long.

While that has disadvantages like you mentioned about maybe doing the 
uncommit twice in a single cycle, the increased responsiveness of the 
application due to memory demands elsewhere might be more important.

How much to shrink? My opinion would be to only shrink if there is a 
huge amount of free memory at this point, i.e. keep that rule simple and 
do the more exact heuristics later (like only considering MaxHeapFreeRatio)

My opinion is to free unused memory asap, so I have a slight preference 
towards also uncommitting during Remark. However that can be added later 
too.

Thanks,
   Thomas