RFR: 8202994: Add support for undoing last TLAB allocation

[JC Beyler]

Hi Per,

It looks kind of weird to me that the method now checks if the obj is
contained in the TLAB but might undo it even if it is not the last
allocation (though it would fail the assertion). Why not just change the
contains to being something like : is_last_allocation and then the test can
be at the top of the method without the need of the second test.

I wonder if you even need a new method then and not just do:


+inline bool ThreadLocalAllocBuffer::undo_allocate(HeapWord* obj,
size_t size) {+  invariants();++  // The object might not be allocated
in this TLAB+  if (obj >= start() && pointer_delta(top(), obj) !=
size) {

+     return false;

+  }

++  set_top(obj);++  invariants();+  return true;+}


Just thought I'd mention it :),
Jc

On Fri, May 11, 2018 at 8:28 AM Aleksey Shipilev <shade at redhat.com> wrote:

> On 05/11/2018 05:17 PM, Per Liden wrote:
> > Updated webrev: http://cr.openjdk.java.net/~pliden/8202994/webrev.1
>
> Looks fine to me.
>
> >> *) Curiosity: why ZGC uses TLABs, not PLABs for these relocations to
> begin with? Shenandoah needs
> >> rewinds like that too, for same reason, and we use PLAB(-like)
> facilities for that, leaving TLABs
> >> for "real" mutator allocations.
> >
> > We haven't really seen the need to introduced the concept of PLABs,
> neither for mutators nor for GC
> > workers. For the most part, an allocation is just an allocation, so we
> naturally just use a
> > mutator's TLAB if there is one. GC workers allocate straight into a
> CPU-local ZPage (same page a
> > mutator on that CPU would allocate a TLAB from). An allocation request
> in ZGC also comes with a set
> > of "allocation flags", which, when needed, can tell us what the
> allocation is for, etc.
> >
> > I suspect it might also help reduce fragmentation a bit (i.e. no PLAB
> waste), but that's secondary
> > and might not even matter much in the end.
>
> Oh yes, fragmentation is something that is helped with separating TLABs
> and PLABs: young objects are
> mostly dead, and relocated objects are usually alive. In Shenandoah, we
> try to separate the two. It
> might not matter for ZGC.
>
> -Aleksey
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180511/84cba73e/attachment.htm>