RFR(XS): 8214235: assertion in collectedHeap.cpp: attempt to clean empty remainder
boris.ulasevich at bell-sw.com
Tue Jan 8 20:33:10 UTC 2019
Thank you all!
08.01.2019 1:32, Hohensee, Paul пишет:
> Then lgtm too.
> 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.
> > 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