RFR: TLAB size flapping

[Roman Kennke]

OK!

Sent from my FairPhoneAm 06.12.2016 6:55 nachm. schrieb Aleksey Shipilev <shade at redhat.com>:
>
> 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 
>
>