RFR: Refactor region flags into FSM
Roman Kennke
rkennke at redhat.com
Thu Aug 24 13:09:23 UTC 2017
Am 23.08.2017 um 15:52 schrieb Aleksey Shipilev:
> We had plenty of bugs caused by inconsistent flags over the regions. Checking them all around
> Shenandoah code is fragile. Turns out, we can make the region state into proper finite state
> machine, and just mechanically nail the transitions between region states, and have all the flags
> derived from those states always consistent.
>
> Webrev:
> http://cr.openjdk.java.net/~shade/shenandoah/region-fsm/webrev.01/
>
> See shenandoahHeapRegion.hpp for FSM description.
>
> The next step would be to common CollectionSet, FreeSet and region flags into a solid
> HeapRegionManager, that will use these states to maintain collection/free-sets, thus providing a
> consistent view over heap for all pieces of Shenandoah code.
>
> Testing: hotspot_gc_shenandoah
>
> Thanks,
> -Aleksey
This looks extremely useful.
Some notes:
+ if (region->is_allocatable() && !heap->in_collection_set(region)) { If
it's allocatable, it should not be in the cset? Also, the heap cset
table should eventually also go elsewhere (HeapRegionManager or however
you want to call it?) Can we have a better name for 'dirty' ? I did that
way back when, and I was lazy, but now kinda regret it. It doesn't
really say what it is. From your description:
+ Transition from "Active" to "Dirty" is reclamation. It can go from
CSet during the normal cycle, + and from {Regular, "Humongous"} for
immediate reclamation. maybe 'reclaimed' ? + if (r->is_empty()) { //
TODO: Should be is_allocatable here, to capture regular regions too? I
think so :-) Otherwise looks good. Roman
More information about the shenandoah-dev
mailing list