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

[Liang Mao]

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.
So do you think resize in "Pause Cleanup" is a better way?

> 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.

Thanks,
Liang






------------------------------------------------------------------
From:Thomas Schatzl <thomas.schatzl at oracle.com>
Send Time:2020 Feb. 11 (Tue.) 20:08
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 12:46, Liang Mao wrote:
> Hi Thomas,
> 
> 
>> 
>>> ....
>>> size_t G1Policy::minimum_desired_bytes(size_t used_bytes) const {
>>>    return _ihop_control->unrestrained_young_size() != 0 ?
>>>             _ihop_control->unrestrained_young_size() :
>>>             _young_list_max_length * HeapRegion::GrainBytes
>>>           + _reserve_regions * HeapRegion::GrainBytes + used_bytes;
>>> }
> 
>> I think G1IHOPControl::_target_occupancy (add a getter) is what you want 
>> to use here (untested).
> 
> I'm not looking for _target_occupancy which is current heap capacity
> because the minimum bytes may exceed it. Since the memory
> usage is almost at peak in remark,
> old_use_bytes + promoted_bytes_in_next_gc + unrestrained_young_bytes
> can be the minimum desired bytes.

You are right, I need to think about this some more.

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.

> 
> 
>> There is a cleaned up version of my earlier change that implements the 
>> latter at http://cr.openjdk.java.net/~tschatzl/8236073/webrev.1/ .
> 
> I have a question that heap size can be shrinked even commit size is not
> changed so it could cause a waste of committed free regions.

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?

Thanks,
   Thomas