RFR: 8202994: Add support for undoing last TLAB allocation

[Aleksey Shipilev]

On 05/11/2018 01:36 PM, Per Liden wrote:
> This patch adds ThreadLocalAllocBuffer::undo_allocate() to undo the allocation made by the last call
> to ThreadLocalAllocBuffer::allocate().
> 
> In ZGC, when a Java thread relocates an object it can use its current TLAB for the new object
> allocation. However, a relocation can later fail, if some other thread won the race to update the
> forwarding information. In those cases, the loosing thread wants to undo its last TLAB allocation.
> This is very similar to the existing PLAB::undo_allocation(), which does the same thing but for PLABs.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8202994
> Webrev: http://cr.openjdk.java.net/~pliden/8202994/webrev.0

*) This condition seems inverted: we need to bail if object is *not* in this TLAB?

  59   // The object might not be allocated in this TLAB
  60   if (contains(obj, size)) {
  61     return false;
  62   }

*) Looking at PLAB::undo_allocation. Do you ever try to revert non-last allocation? E.g. do you
really need that path in new code, or you just want to assert it, like PLAB code does?

*) 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.

Thanks,
-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/6a771d29/signature.asc>