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

Thomas Schatzl thomas.schatzl at oracle.com
Tue Feb 11 12:08:02 UTC 2020


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?


More information about the hotspot-gc-dev mailing list