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