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