does C1+CMS miss a storestore membar in jdk8u-shenandoah?

12 Dec 2019

      Hi,  Aarch64 & PowerPC community,

I think this is only for arm and ppc because only they are use relaxed
memory ordering.  x86 and sparc use TSO so storestore membar doesn't matter
for them. please correct me if I am wrong.

I feel that C1's
LIRGenerator::CardTableModRef_post_barrier(c1_LIRGenerator.cpp) misses a
storestore membar for CMS on jdk8u.  Could you review my observation? If I
am right, I'd like to file a bug and fix it.

One reference is oop.inline.hpp. CMS uses the following function:
  template <class T> inline void oop_store(volatile T* p, oop v)
It will emit a write_mem_barrier before cardTable updates.

Another reference  is C2 code. GraphKit::write_barrier_post generates
storeCM for CMS.
  // Smash zero into card
  if( !UseConcMarkSweepGC ) {
    __ store(__ ctrl(), card_adr, zero, bt, adr_type, MemNode::release);
  } else {
    // Specialized path for CM store barrier
    __ storeCM(__ ctrl(), card_adr, zero, oop_store, adr_idx, bt, adr_type);
  }

Actually, it's not  only C1 has this bug. Template interpreter has this
problem too. It only happens for aarch64.  do_oop_store in
templateTable_aarch64.cpp doesn't have any membar for CMS.  By contrast,
ppc64 does have a membar(StoreStore).

(macroAssembly_ppc.cpp)

// Write the card table byte.
void MacroAssembler::card_table_write(jbyte* byte_map_base, Register Rtmp,
Register Robj) {
  assert_different_registers(Robj, Rtmp, R0);
  load_const_optimized(Rtmp, (address)byte_map_base, R0);
  srdi(Robj, Robj, CardTableModRefBS::card_shift);
  li(R0, 0); // dirty
  if (UseConcMarkSweepGC) membar(Assembler::StoreStore);
  stbx(R0, Rtmp, Robj);
}

I also check the jdk11 and jdk14,  c1 and template interpreter both
consider concurrent_scanning case.  please check out the following
functions. so only jdk8u is at risk.
CardTableBarrierSetC1::post_barrier
CardTableBarrierSetAssembler::store_check

thanks,
--lx

Liu Xin

Doerr, Martin

tags

participants (2)