RFR: FreeSet refactorings, cleanups, improvements (a pack of 7)

Roman Kennke rkennke at redhat.com
Thu Mar 29 11:22:09 UTC 2018


Looks good.

Roman


> http://cr.openjdk.java.net/~shade/shenandoah/freeset-refactor/webrev.01/
> 
> This pack is the preparation for evac-reserve and degen-evac work, but it is self-sufficient in
> itself. It includes:
> 
>  *) sh-heap-refs: FreeSet and HeapRegion should have the reference to ShenandoahHeap
> 
>   Instead of polling ShenandoahHeap::heap(), we should reuse the fields already available for us.
>   FreeSet needs to have the field added first.
> 
>  *) freeset-build-refactor: Refactor FreeSet rebuilding into the single source
> 
>   Instead of having the free set rebuilding loops all over the GC code, centralizes the rebuilding
>   in FreeSet::rebuild.
> 
>  *) freeset-trash: FreeSet should accept responsibility over trashed regions
> 
>   Current mechanics only adds "allocatable" regions into the FreeSet, and "trash" regions are
> dangling in the heap. FreeSet calls into heap to recycle some trash if allocation failed. Not only
> this trips out the code that polls "free" from the heap and FreeSet, that does not count trash, it
> also makes FreeSet make a few scans over. I.e. in some cases it would do scan (no free found) ->
> recycle -> scan again.
> 
>  The better idea is to make FreeSet responsible for trash regions too, and recycle them as it goes
> through the allocation path. Asynchronous cleanup would still assist FreeSet in recycling the
> regions, and so normally FreeSet would not recycle itself.
> 
>  *) merge-trash: Drop distinction between immediate garbage and free in heuristics
> 
>  Heuristics cleanup: now that FreeSet took over responsibility over trash, we do not need any
> distinction between immediate garbage and actual free. Simplifies heuristics logic.
> 
>  *) shortcut-full: Do not add non-allocatable regions to the FreeSet
> 
>  In heavily populated heap, we would add completely full regions into the FreeSet (because they are
> regular!), which takes time during allocation scans. We should never put those in FreeSet for
> performance reasons.
> 
>  *) pacer-poll-freeset: Pacer should poll FreeSet to figure out actually available space
> 
>  Pacer polls SH::used() to figure out the amount of free space available. Unfortunately, this
> underestimates the amount of free space, because there are trashed regions that are almost
> immediately allocatable, but still count as used. Let Pacer poll the FreeSet to know the available
> free space.
> 
>  *) freeset-remove-add: Remove FreeSet::add_region, inline into FreeSet::rebuild
> 
>  Coalesces now-unused add_region into rebuild, optimizes it a bit.
> 
> 
> Testing: hotspot_gc_shenandoah, allocation pressure benchmarks
> 
> Thanks,
> -Aleksey
> 




More information about the shenandoah-dev mailing list