RFC: Adaptively resize heap at any GC/SoftMaxHeapSize for G1

[Thomas Schatzl]

Hi,

On 18.06.20 11:01, Liang Mao wrote:
> Hi Thomas,
> 
> Sorry for replying this late. It's great to see the good progress of the approach
> we've disscussed for a while. Resizing at any GC is definitly the right way. I have
>   some quetions in inlined comments below.
> 
> BTW, I want to answer some questions in advance:
> 1) We may not be able to test this approach in our work loads recently since the versions
> are quite different. But we shall want to merge this and further concurent uncommit stuff
>   together later in JDK11.

Okay. We also expect this to land close together with the concurrent 
uncommit in latest jdk/jdk.

> 2) JEP 346 is backported to our JDK11 and works fine as expected in some work loads. I guess
> the new elastic solution in future would be better:)
> 3) The previous humongous proposal by aborting initial mark solved some problems but still had
> the issue of frequent GC. We are now tunning this and verifying in our work loads.

Okay. We are still working on this as it is a good idea to do, we only 
think that this change and the concurrent uncommit are more important.

Maybe you have noticed the discussions with Ziyi Luo from Amazon who is 
also currently working on improving adaptive IHOP. There may be some 
synergies in the overall effect here.
>> ------------------------------------------------------------------
>> From:Thomas Schatzl <thomas.schatzl at oracle.com>
>> Send Time:2020 Jun. 10 (Wed.) 17:31
>> To:hotspot-gc-dev at openjdk.java.net <hotspot-gc-dev at openjdk.java.net>
>> Subject:RFC: Adaptively resize heap at any GC/SoftMaxHeapSize for G1
> 
>> Hi all, Liang,
> 
>>    after a few months of busy working in the area of G1 heap resizing
>> and ultimately SoftMaxHeapSize support, I am fairly okay with a first
>> preview of these associated changes. So I would like to ask for feedback
>> on the current changes for what I intend to complete in the (early)
>> jdk16 timeframe.
> 
>> This is not a request for review of the changes for pushing, although
>> feedback on the code is also appreciated.
> [...]
>> (5) is the main change that implements a what has been mentioned above:
>> G1 tries to keep actual GC time ratio within the range of
>> LowerGCTimeRatio and GCTimeRatio. As long as actual GC time ratio is
>> within this range, no action occurs. As soon as it finds that there is a
>> trend of being outside, it tries to correct for that, internally trying
>> to reach an actual gc time ratio in the middle of that range.
> 
> Mostly I have some concerns in this change:
> a) i didn't see you change the default GCTimeRatio in G1. Do you think the lowbound
>   of 6 would be too low? I don't have a precise number but intuitively at least around 10
> seems more safer for those online interactive applications. That means we have 20
> as the default GCTimeRatio for G1.

As mentioned in the original email at the end I am considering changing 
the default of GCTimeRatio, probably increasing it to get more 
aggressive behavior. Whether 20 or some other value needs to be 
determined yet.

Note that for resizing (at this time) G1 would target a GCTimeRatio of 
15 (midpoint of the range).

Also I noticed that it might be good to make the target range tighter 
for larger values of GCTimeRatio (it makes a lot of difference whether 
we are currently on average at 12 or 18 in this example). Otherwise g1 
might not decrease heap size in many cases. Need to think about this.

The reason for changing the gctimeratio defaults is not only this 
change, but over the years G1 has improved so much in pause time 
performance that a change is imho warranted. Since g1 previously did not 
really return memory that much, a higher value would increase overall 
memory usage a lot, while g1 will be much more dynamic (for better or 
worse).

This will be a different follow-up change. Thank you for your input 
about this, I filed JDK-8247843 to follow up.

> b) It's a known issue about mixed GC. We know that mixed GC would severely decay
> the GC time ratio. (I have no test result for abortable mixed gc after JDK12.) I'm not
> sure if some work loads with heavy mixed GC would easily decrease the heap size. Or
> abortable mixed GC can roughly make sure the GC time ratio in mixed GC phases is above
> 50% of normal young GC?gc time 

This issue has hopefully been fixed (or at least improved) in 8244603 
and 8238858 which are out for review.

In my testing, the increase in actual GCTimeRatio during mixed gc is now 
much much lower.

The changes will likely land next week in jdk/jdk (just missed 15).

Thanks,
   Thomas