RFR: Make partial GC concurrent

[Aleksey Shipilev]

On 10/09/2017 02:15 PM, Roman Kennke wrote:
> Am 06.10.2017 um 21:11 schrieb Roman Kennke:
>>>   *) There is some weird interaction between ShenandoahKeepAliveBarrier and new concurrent partial
>>> code. MacroAssembler::keep_alive_barrier would call shenandoah_write_barrier_pre, and that only get
>>> executed when concurrent mark is active. Shouldn't it execute when concurrent partial is active too?
>>> This gets weirder when ShenandoahBarrierSet::keep_alive_barrier executes WB when conc-partial is in
>>> progress, but MacroAssembler::keep_alive_barrier does not.
>> Yes, it looks weird but is actually correct.
>> In order to keep an object alive during conc partial, we *would* need a write barrier, I have done
>> it this way in the runtime barriers. We must not enqueue the object to keep alive in the SATB
>> queues, we use this for different purpose. I haven't added those write-barriers to the
>> interpreter, c1 and c2 paths though, for 2 reasons:
>>  1. they are only used to support Reference.get() (as opposed to runtime, where it's also used for
>> stuff like string table), and we don't do special reference processing (yet) in conc partial.
>>  2. I got some weird errors when adding write-barriers in interpreter (iirc), because it's used in
>> a strange place and messes up the stack frame. This would require work if we ever want to support
>> ref processing during conc partial, but I decided against it for now.

Okay. Can we at least add the assert in weak_ref_process-something that we are not in concurrent
partial path? So that we would know exactly what we are dealing with if weakref processing is
accidentally enabled?


> http://cr.openjdk.java.net/~rkennke/concpartial/webrev.02/

This looks very good to me.

*) I think we can make ShenandoahBarrierSet::write_ref_array path easier, if we first check for
UseShenandoahMatrix, and have a single "else" branch. But this can be done later.

*) Seems like enabling the flags in ShenandoahPartialHeuristics constructor should be unconditional,
like we do with UseShenandoahMatrix in the same method? Running partial without these barriers is an
obvious error.

Thanks,
-Aleksey