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