RFR(S): 7121496: G1: do the per-region evacuation failure handling work in parallel
tony.printezis at oracle.com
Wed Dec 28 12:03:22 UTC 2011
Thanks for doing this, it looks good. A few comments:
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;
This is fine but we already have:
Can you maybe introduce reset_cset_heap_region_claim_values() for
BTW, I liked that you declared the update_rset_cl once per task.
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:
> 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
> 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.
More information about the hotspot-gc-dev