RFR: Refactor region flags into FSM

[Zhengyu Gu]

On 08/24/2017 09:09 AM, Roman Kennke wrote:
> 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
> 


Fail to commit an uncommitted region, does not necessarily mean 
out-of-memory, you may still have plenty regions in free set after this 
region, may make sense to have free set to skip this region and continue?

-Zhengyu