RFR: 8202994: Add support for undoing last TLAB allocation
shade at redhat.com
Fri May 11 15:28:02 UTC 2018
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the hotspot-gc-dev