RFR(X): Reduce region retirement during tlab allocation

Zhengyu Gu zgu at redhat.com
Fri May 5 22:26:15 UTC 2017


I don't see any ping-pong effects. I do see some uneven TLAB sizes, 
which suggest that we actually pick up those, otherwise to be retired 
regions.

137.832s][debug][gc,alloc] Allocate new tlab, requested size = 524288 bytes
[137.833s][debug][gc,alloc] Allocate new tlab, requested size = 524288 bytes
[137.834s][debug][gc,alloc] Allocate new tlab, requested size = 524288 bytes
[137.838s][debug][gc,alloc] Allocate new tlab, requested size = 27704 bytes
[137.838s][debug][gc,alloc] Allocate new tlab, requested size = 373640 bytes
[137.926s][debug][gc,alloc] Allocate new tlab, requested size = 122944 bytes
[138.034s][debug][gc,alloc] Allocate new tlab, requested size = 524288 bytes
[138.041s][debug][gc,alloc] Allocate new tlab, requested size = 2656 bytes
[138.042s][debug][gc,alloc] Allocate new tlab, requested size = 521632 bytes
[138.090s][debug][gc,alloc] Allocate new tlab, requested size = 2688 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 521600 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 521600 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 521600 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 2688 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 521600 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 521600 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 2672 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 2696 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 2704 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 2712 bytes
[138.863s][debug][gc,alloc] Allocate new tlab, requested size = 3360 bytes


OK?

Thanks,

-Zhengyu


On 05/05/2017 05:07 PM, Roman Kennke wrote:
> Am 05.05.2017 um 22:11 schrieb Zhengyu Gu:
>> Current implementation of unsafe_max_tlab_alloc() peeks current region
>> size in free set and tries to use its remaining space. However, the
>> current region is very likely just been consumed with very little or
>> no memory left, then it returns region size as fallback. This can
>> result the calculated tlab size too big, and causes too many regions
>> to retire while they still have fair amount of free space.
>>
>> When current region is too small for tlab, we can look ahead of next
>> available region and use its size as hint. The approach seems to cut
>> down retired region with usable space. As the result, we see less GC
>> cycles.
>>
>>
>> Ran Derby test with 1g heap.
>>
>> Before:
>> http://cr.openjdk.java.net/~zgu/shenandoah/region_retirement/unpatched.stats.txt
>>
>> After:
>> http://cr.openjdk.java.net/~zgu/shenandoah/region_retirement/patched.stats.txt
>>
>> Webrev:
>> http://cr.openjdk.java.net/~zgu/shenandoah/region_retirement/webrev.00/index.html
>>
>> Test:
>>
>>   hotspot_gc_shenandoah.
>
> Nice one!
>
> Please make sure you don't get funny ping-pong effects in TLAB sizing.
> We have seen this before. If TLAB sizing doesn't flap around, it's good
> to go from my side.
>
> Roman
>


More information about the shenandoah-dev mailing list