RFR: 8205924: ZGC: Premature OOME due to failure to expand backing file

Erik Helin erik.helin at oracle.com
Wed Jul 4 10:01:09 UTC 2018


On 07/04/2018 11:57 AM, Per Liden wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8205924
>>> Webrev: http://cr.openjdk.java.net/~pliden/8205924/webrev.0
>>
>> This looks good to me, I would have added an assert in
>> size_t ZPhysicalMemoryBacking::try_expand such as
>>
>> +size_t ZPhysicalMemoryBacking::try_expand(size_t old_capacity, size_t 
>> new_capacity) {
>> +  assert(new_capacity > old_capacity, "invariant");
>> +  const size_t capacity = _file.try_expand(old_capacity, new_capacity 
>> - old_capacity, _granule_size);
>>
>> Not because I spotted anything wrong with this patch, more because if 
>> someone one day introduces such a bug, then it will be hell to debug 
>> without an assert like the above one :)
> 
> Sounds good, will add that.

Ok, good!

>>
>> In ZPageAllocator::try_ensure_unused_for_pre_mapped I would maybe have 
>> designed ZPhysicalMemoryManager::try_ensure_unused_capacity so that it 
>> is always valid to call (the method would just return in case _backing 
>> isn't initialized).
> 
> I would prefer to keep that check in 
> ZPageAllocator::try_ensure_unused_for_pre_mapped(), since that function 
> is a special case since it's called during construction. The underlying 
> ZPhysicalMemoryManager::try_ensure_unused_capacity() should never be 
> called if the ZPhysicalMemoryManager isn't initialized and I'd rather 
> crash hard than silently return if someone does that mistake.

Ok, that sounds good to me, just keep it the way it is then.

>> I don't need to see another webrev if you just add the assert, but 
>> please send out a new version if you rework ZPhysicalMemoryManager.
> 
> Thanks for reviewing, Erik!

Since you only adding the assert, I'm fine with this now, Reviewed.

Thanks,
Erik

> cheers,
> Per



More information about the hotspot-gc-dev mailing list