RFR: Implement barriers to maintain connection matrix

[Roman Kennke]

Am 02.03.2017 um 11:13 schrieb Aleksey Shipilev:
> On 03/01/2017 08:37 PM, Roman Kennke wrote:
>> http://cr.openjdk.java.net/~rkennke/thematrix/webrev.00/
> *) c1_LIRGenerator.cpp:
>
> T_LONG does not sound right here. C1 should have something to deal with native
> pointer width?
>
> 1683   LIR_Opr tmp4 = new_register(T_LONG);
> 1684   __ move(LIR_OprFact::intptrConst((intptr_t) matrix->matrix_addr()), tmp4);
Ok, right. new_pointer_register() does the right thing there.

> *) referenceProcessor.cpp:
>
> That trailing boolean arg is obscure:
>
>  901   oop retest;
>  902   if (UseShenandoahGC && UseShenandoahMatrix) {
>  903     retest = oopDesc::atomic_compare_exchange_oop(next_discovered,
> discovered_addr,
>  904                                                   NULL, true);
>  905   } else {
>  906     retest = oopDesc::atomic_compare_exchange_oop(next_discovered,
> discovered_addr,
>  907                                                   NULL);
>  908   }
>
> Is this just:
>
>  oop retest = oopDesc::atomic_compare_exchange_oop(next_discovered,
> discovered_addr, (UseShenandoahGC && UseShenandoahMatrix));
Yes, changed.

> *) shenandoahConcurrentMark.cpp, ShenandoahRefProcTaskProxy.work:
>
> Am I blind, or the newly added branch under UseShenandoahMatrix is the same as
> the branch on "else" path?
Uhhh, forgot to finish that part :-) Fixed too.

> *) shenandoahHeap.cpp, ShenandoahHeap::prepare_for_concurrent_evacuation()
>
> Bad indent.
Fixed.

> *) shenandoahOopClosures.hpp
>
> Confused why ShenandoahMarkRefsMatrixClosure uses CONCURRENT while
> ShenandoahMarkRefsMetadataMatrixClosure uses NONE. These two should use the
> same, no?

Right. Fixed.
> *) macro.cpp
>
> Put assert(UseShenandoahGC) here:
>
>  314   } else {
>  315     C->shenandoah_eliminate_matrix_update(p2x, &_igvn);
Fixed too.

> Otherwise looks good.
http://cr.openjdk.java.net/~rkennke/thematrix/webrev.01/

Ok now?

Roman