RFR: Implement barriers to maintain connection matrix

Aleksey Shipilev shade at redhat.com
Thu Mar 2 10:13:31 UTC 2017


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

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

*) shenandoahConcurrentMark.cpp, ShenandoahRefProcTaskProxy.work:

Am I blind, or the newly added branch under UseShenandoahMatrix is the same as
the branch on "else" path?

*) shenandoahHeap.cpp, ShenandoahHeap::prepare_for_concurrent_evacuation()

Bad indent.

*) shenandoahOopClosures.hpp

Confused why ShenandoahMarkRefsMatrixClosure uses CONCURRENT while
ShenandoahMarkRefsMetadataMatrixClosure uses NONE. These two should use the
same, no?

*) macro.cpp

Put assert(UseShenandoahGC) here:

 314   } else {
 315     C->shenandoah_eliminate_matrix_update(p2x, &_igvn);

Otherwise looks good.

Thanks,
-Aleksey





More information about the shenandoah-dev mailing list