RFR: Make partial GC concurrent

[Roman Kennke]

Am 09.10.2017 um 14:53 schrieb 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?

Added.

>> 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.
I left that alone for now.
> *) 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.

Ok, did that.

I also discovered some bugs in my previous webrev (caused mostly by the 
1st iteration in response to your comments...):
- The split between ShenandoahSATBBarriers and ShenandoahConditionalSATB 
barriers lead to some omitted SATB barriers where we need them.
- Having different # of workers for stw vs. conc phases means we need to 
process extra queues at the beginning of conc phase (much like in 
conc-marking).

Differential webrev:
http://cr.openjdk.java.net/~rkennke/concpartial/webrev.03.diff/ 
<http://cr.openjdk.java.net/%7Erkennke/concpartial/webrev.03.diff/>
Full webrev:
http://cr.openjdk.java.net/~rkennke/concpartial/webrev.03/ 
<http://cr.openjdk.java.net/%7Erkennke/concpartial/webrev.03/>

Good now?

Roman