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

[Thomas Schatzl]

Hi,

On 11.02.20 13:52, Liang Mao wrote:
> Hi Thomas,
> 
>> I think the calculation assumes that the next gc is the first mixed gc, 
>> which isn't true, there's that "Prepare Mixed" GC too. But as an initial 
>> approximation it should work.
> 
> I assumed the prepare mixed GC. But technically we need the promotion
> bytes in 1st mixed GC too, right? After I took a look at gc
> log, i found there could be several normal young GC between remark
> and "Prepare Mixed" GC because it cost time to do some cleanup.

Actually, building the remembered sets.

> So do you think resize in "Pause Cleanup" is a better way?

I am certainly not opposed to moving resizing to the cleanup pause or 
anywhere else (last mixed gc?) where it makes most sense. Moving to 
Cleanup would likely make prediction about the "needed" memory easier.

>> You mean because of regions being larger than the commit size or other 
>> reasons? I.e. you have 2M large pages but only 1M regions, so you may 
>> end up with G1 not being able to actually uncommit as only half of that 
>> 2M page is free?
> 
> No. Sorry for my unclear discription. My point is update_heap_target_size
> can happen in every normal GC but in remark real shrink may never happen
> (the large MaxHeapFreeRatio will prevent the shrinking).
> So we may use smaller heap size but no regions are uncommitted.

that is true, that is the same issue I wanted to point out with my 
earlier remark about "The resizing logic change could be handled under 
JDK-8238686, although this change does not modify the use of 
MaxHeapFreeRatio. " - i.e. does not uncommit space due to MaxHeapFreeRatio.

That may be handled separately if it is easier; JDK-8238686 suggests to 
think about removing the use of Min/MaxHeapFreeRatio alltogether (or 
maybe use only during full gc).

> 
> Thanks,
> Liang
> 

Hth,
   Thomas