RFR: FreeSet refactor: bitmaps, cursors, biasing
Zhengyu Gu
zgu at redhat.com
Tue Sep 19 15:20:46 UTC 2017
Looks good to me.
-Zhengyu
On 09/19/2017 10:24 AM, Aleksey Shipilev wrote:
> http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/webrev.01/
>
> This is actually 3-in-1 patch, because there is a fair amount of cohesion between all of them. Brief
> tour of changes:
>
> *) Allocation code moved from ShenandoahHeap to ShenandoahFreeSet. This will soon become the
> ShenandoahHeapRegionManager, if you see where it goes. The API is cleaned up a bit, and privately
> used methods are now really private.
>
> *) FreeSet now maintains the bitmap instead of collection of regions. This allows maintaining the
> sorted view of free regions, which is important when asynchronous recycling works. Async recycling
> may add regions in random order, and humongous allocation would be unhappy about that. The bitmap
> also allows resuming the allocation at the "earlier" region once it is added, making footprint story
> easier.Goo
>
> *) FreeSet maintains two boundary cursors, "leftmost" and "rightmost", that bound the bitmap. This
> serves as the optimization for allocation path, because it can look up either boundary and see the
> free region there. We could, in principle, use the optimized bitmap scans in future to make the
> allocation in ragged heap even faster.
>
> *) Two boundary cursors also allow _biasing_ the allocations to either end. Biasing application
> allocations help to optimize allocation path even further, because we clean up the beginning of heap
> most of the time.
>
> Testing: hotspot_gc_shenandoah, benchmarks, eyeballing Visualizer
>
> LRU running under Visualizer with this change:
> http://cr.openjdk.java.net/~shade/shenandoah/freeset-bitmaps/lru.mp4
>
> Thanks,
> -Aleksey
>
More information about the shenandoah-dev
mailing list