RFR: 8202994: Add support for undoing last TLAB allocation

Per Liden per.liden at oracle.com
Fri May 11 15:17:35 UTC 2018


Hi Aleksey,

Thanks for looking at this.

On 05/11/2018 03:23 PM, Aleksey Shipilev wrote:
> 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   }

Mama! That doesn't look right, thanks for spotting!

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

I can't think of a reason why we would need it to return false in this 
case, so I'll make it an assert instead.

Updated webrev: http://cr.openjdk.java.net/~pliden/8202994/webrev.1

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

Thanks!
/Per

> 
> Thanks,
> -Aleksey
> 


More information about the hotspot-gc-dev mailing list