RFR: Refactor region flags into FSM

[Roman Kennke]

Okidoki

Am 24. August 2017 18:38:58 MESZ schrieb Aleksey Shipilev <shade at redhat.com>:
>On 08/24/2017 03:09 PM, Roman Kennke wrote:
>> + if (region->is_allocatable() && !heap->in_collection_set(region)) {
>> If it's allocatable, it should not be in the cset?
>
>Yes. Fixed. There is one other place where checking against cset
>collection is sensible, because
>region flags are not yet set. But here, we can rely on flags.
>
>Also renamed is_allocatable() -> is_alloc_allowed().
>
>> Also, the heap cset table should eventually also go elsewhere
>(HeapRegionManager or however you
>> want to call it?)
>Yes. Whatever it is called, it should sync up the region flags and cset
>bitmap.
>ShenandoahCollectionSet does it now (crudely), and it should get
>better.
>
>> 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. 
>
>Yes, good call! heap_region_iterate thinks "dirty" is "cset". Renamed
>to "Trash", as discussed.
>
>> + if (r->is_empty()) { // TODO: Should be is_allocatable here, to
>capture regular regions too? 
>> I think so :-) 
>
>This is the left-over from Christine's LRU/Generational work. We have
>discussed it briefly, and
>agreed that we can add regular regions there too. But, I want to have
>it in a separate changeset
>anyway, in case of regressions.
>
>New webrev:
>  http://cr.openjdk.java.net/~shade/shenandoah/region-fsm/webrev.02/
>
>Still passes hotspot_gc_shenandoah.
>
>Thanks,
>-Aleksey

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.