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

Liang Mao maoliang.ml at alibaba-inc.com
Wed Feb 12 10:17:15 UTC 2020


Hi Thomas,

I made a new patch for the issues we listed in JDK-8238686 and
JDK-8236073:
http://cr.openjdk.java.net/~luchsh/8236073.webrev.3/

Main changes are:
1) Don't use MinHeapFreeRatio in concurrent mark stage to guarantee
the minimal commit size as we discussed. I use the IHOP prediction
instead. 

2) Remove resize_heap_if_necessary in remark. Heap expansion
will be based on 1)  in concurrent mark cleanup pause but there is
no shrink at that time

3) Heap shrink will happen after mixed GC(s). I use 3 number to 
determine the target capacity: a) maximum_desired_capacity by
MaxHeapFreeRatio(here I still use MaxHeapFreeRatio because it is
unified with full gc, 30% of live objects make sence);
b) minimum_desired_bytes predicted in 1) in cleanup pause(to make sure
we will not do a shrink just after an expansion);
c) soft_max_capacity

4) expand/shrink logic are moved into sizing policy.

Apparently, it solves the issues in both JDK-8238686 and JDK-8236073.

I have performanced the original specjbb2015 test and it looks fine.  The
test will not commit memory so aggressive as original in remark and it
is able to shrink  heap after changing SoftMaxHeapSize(2500M) via
 jinfo. The heap capacity will drop from ~3G to 2500m. The new flow
can work with JEP 346 and benifit it for better memory saving.

The only remaining problem is shrinking heap after mixed GCs may not
happen on time if application is in "idle". We may still need a timer to
 make sure mixed GC can happen? 


Thanks,
Liang






------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2020 Feb. 11 (Tue.) 21:27
To:"MAO, Liang" <maoliang.ml at alibaba-inc.com>; hotspot-gc-dev <hotspot-gc-dev at openjdk.java.net>
Subject:Re: RFR: 8236073: G1: Use SoftMaxHeapSize to guide GC heuristics

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



More information about the hotspot-gc-dev mailing list