RFR: 8202994: Add support for undoing last TLAB allocation

[Aleksey Shipilev]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180511/fe32b950/signature.asc>