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

[Hohensee, Paul]

Then lgtm too.

Thanks,

Paul

On 1/7/19, 5:24 AM, "Per Liden" <per.liden at oracle.com> wrote:

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