RFR(S): 7121496: G1: do the per-region evacuation failure handling work in parallel

[Tony Printezis]

John,

Thanks for doing this, it looks good. A few comments:

g1CollectedHeap.cpp:

4102     assert(_g1h->g1_policy()->assertMarkedBytesDataOK(), "Should be!");

Since this will now be executed concurrently with other workers doing 
the self-forward removal it might pick up inconsistent information (not 
100% sure that this will be the case, but I'd like be careful!). Why 
don't you stop calling it per region and only call it once at the start 
of remove_self_forwarding_pointers() (it's already called at the end).

4192   // Now reset the claim values in the regions in the collection set.
4193   ResetClaimValuesClosure reset_cv_cl;
4194   collection_set_iterate(&reset_cv_cl);

This is fine but we already have:

reset_heap_region_claim_values()
check_heap_region_claim_values()

and

check_cset_heap_region_claim_values()

Can you maybe introduce reset_cset_heap_region_claim_values() for 
consistency?

BTW, I liked that you declared the update_rset_cl once per task.

Tony

On 12/23/2011 02:29 PM, John Cuthbertson wrote:
> Hi Everyone,
>
> Can I have a couple of volunteers look of this set of changes? The 
> webrev can be found at: 
> http://cr.openjdk.java.net/~johnc/7121496/webrev.0/
>
> Summary:
> The work that gets done for each heap region in the collection set, in 
> the event of an evacuation failure, (e.g. removing self-forwarding 
> pointers, updating the BOT etc.) was serial. I parallelized it by 
> simply wrapping the work done for each region inside a HeapRegion 
> closure, whose doHeapRegion method claims a region and does the work 
> for that region. This HeapRegion closure is, in turn, wrapped in an 
> AbstractGangTask.
>
> Testing: GC test suite with both deferred and immediate RSet updates 
> (in some of the configurations - SPECjbb2000, SPECjbb2005, and 
> GCBasher can experience a number of evacuation failures); Kitchensink 
> with a forced evacuation failure mechanism.
>
> Thanks,
>
> JohnC
>
>