RFR: 8139149: Split G1 evacuate_collection_set into multiple steps

[Mikael Gerdin]

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)