RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder

Per Liden per.liden at oracle.com
Mon Jan 7 13:23:54 UTC 2019


On 1/7/19 11:01 AM, Thomas Schatzl wrote:
> Hi all,
> 
> On Mon, 2018-12-31 at 15:26 +0000, Hohensee, Paul wrote:
>> Yes, please proceed with the fix to tlab_alloc_reserve(). The
>> original assert was doing its job of detecting a bug.
>>
>> You're correct, I was looking at
>> http://cr.openjdk.java.net/~bulasevich/8214235/webrev.01/. In that,
>> chunks less than min_fill_size() could be left unfilled. Unlikely,
>> but possible given a bug somewhere else.
>>
>> In http://cr.openjdk.java.net/~bulasevich/8214235/webrev.00/, if the
>> space available between top() and hard_end() is less than
>> min_fill_size(), fill_with_dummy_object() should assert.
>>
> 
> The .00 patch is the correct and most space-efficient one.
> 
> As described earlier, if the VM can always fit a minimum sized object
> in any remainder, we do not need a tlab alloc reserve (i.e. end ==
> hard_end).
> 
> The suggested change in CollectedHeap::tlab_alloc_reserve() would just
> waste some memory in these cases.

I agree with what Thomas is saying here and also prefer the .00 patch.

cheers,
Per

> 
> This is e.g. the case on 32 bit systems with ObjectAlignmentInBytes>=8
> (the default) where the minimum instance size is 8 bytes, or on 64 bit
> systems with ObjectAlignmentInBytes>=16 where minimum object instance
> is 16 bytes.
> 
> A better check instead of "top() < hard_end()" would be "top() !=
> hard_end()" - as in this case, if Universe::fill_with_dummy_object() is
> still not able to fill in an object (it should if everything has been
> done correctly), it would assert for us. Basically in case objects are
> not aligned correctly.
> 
> (I already tried to suggest something like that in
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2018-November/024092.html
>   , but re-reading my answer it may not have been clear enough).
> 
> Thanks,
>    Thomas
> 
> 


More information about the hotspot-gc-dev mailing list