RFR: TLAB size flapping

[Aleksey Shipilev]

On 12/06/2016 06:26 PM, Roman Kennke wrote:
>> We enter the slow path *twice* per region, instead of doing it once.
>> I think
>> returning MinTLABSize is wrong in the code above, and we have two
>> options:
>>   a) Return 0 on MinTLABSize branch. If I read the code right, this
>> will bail us
>> from TLAB allocation path, which is undesireable;
>>   b) Advance to the next free region, and try to poll its free().
> 
> Hmm, a seems undesirable. Do we really need to advance to next region?
> Can't we simply return region-size here? I mean, it is inherently racy
> and it doesn't matter if we advance right now, or a little later when
> trying to allocate. Returning X here doesn't somehow magically
> guarantee that we can later allocate X without skipping to next region.
> Unless it's somehow done atomically. Which we don't. (Shenandoah does
> lock-free allocations, maybe other GCs are better off because they
> allocate under Heap_lock?)

Ah, very good, we can return the region size, knowing the next free region is
completely free:
  http://cr.openjdk.java.net/~shade/shenandoah/tlab-flapping/webrev.01/

It does seem to improve allocation rates when multiple allocating threads are
bashing us with requests (caveat emptor: new workload, blah-blah):
 http://cr.openjdk.java.net/~shade/shenandoah/tlab-flapping/baseline.txt
 http://cr.openjdk.java.net/~shade/shenandoah/tlab-flapping/patched.txt

Thanks,
-Aleksey