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