RFR: 8139149: Split G1 evacuate_collection_set into multiple steps

[Mikael Gerdin]

Hi Erik,

On 2015-10-27 12:19, Erik Helin wrote:
> 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.

I did get some feedback from Thomas to avoid the _ext method and instead 
make the external implementation responsible for calling the standard 
evacuate_colletion_set, as in:

http://cr.openjdk.java.net/~mgerdin/8139149/webrev.0_to_1/
http://cr.openjdk.java.net/~mgerdin/8139149/webrev.1

/Mikael


>
> 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)