RFR: 8139149: Split G1 evacuate_collection_set into multiple steps

[Erik Helin]

Hi Mikael,

thanks for doing this tricky but very appreciated patch! It is really
hard to verify that there are no dependencies between the moved lines,
but after staring at the code for quite some time, I think the patch is
good to go. Reviewed.

Thanks,
Erik

On 2015-10-16, Mikael Gerdin wrote:
> Hi all,
> 
> I'd like to split up one of G1's main functions, evacuate_collection_set,
> into different steps.
> 
> I also add a hook to allow an implementor to add code for additional
> evacuation other than the standard collection set.
> 
> The actual change is not that large but it does introduce some re-orderings
> of operations which I will try to argue are correct:
> 
> * set_evacuation_failure_alot_for_current_gc is moved but its result is only
> accessed from copy_to_survivor_space which is still after where I put it.
> 
> * prepare_for_oops_into_collection_set_do is moved to below disabling the
> hot card cache, this should not be an issue since draining the hot card
> cache is done during updateRS which is a later phase.
> 
> * cleanup_after_oops_into_collection_set_do ends up before releasing of
> alloc regions but the alloc region release currently does not interact with
> card dirtying so it should be fine.
> 
> * removal of self forward pointers for evacuation failure and reference
> enqueue will end up occurring before
> -> alloc region release
> -> par scan thread state flushing
> -> evac summary stats
> -> hot card cache re-enable
> -> code root memory purge
> Both evacuation failure processing and reference enqueue should not perform
> any allocation, so alloc region release and summary stats should not be
> affected.
> 
> Both evacuation failure processing and reference enqueue does mutate the
> card table in order to restore remembered sets. This is the primary reason
> for them being forced to occur after
> cleanup_after_oops_into_collection_set_do which clears the entire card
> table.
> Par scan thread state flushing does flush the dirty card buffers created
> during the collection to the collections dcq set but actually dirtying those
> cards in the card table is done during the redirty_logged_cards step which
> does not move in this change.
> 
> Moving the hot card cache re-enable should only affect cards refined during
> concurrent refinement after the current gc is completed.
> 
> The code root memory purge is independent of the other changes so it should
> not have any visible effect.
> 
> Please don't just take my word for this though, I might have missed
> something!
> 
> 
> Webrev: http://cr.openjdk.java.net/~mgerdin/8139149/webrev.0/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8139149
> 
> Testing:
> JPRT
> RBT (Kitchensink, vm.gc.testlist, :hotspot_all jtreg tests)