Hi lx, seems like the following issue should get backported: https://bugs.openjdk.java.net/browse/JDK-8135018 Btw. I believe PPC is fine because C1 is not supported in 8u (at least not in the official repo). Best regards, Martin
-----Original Message----- From: jdk8u-dev <jdk8u-dev-bounces@openjdk.java.net> On Behalf Of Liu Xin Sent: Donnerstag, 12. Dezember 2019 08:40 To: aarch64-port-dev@openjdk.java.net; ppc-aix-port- dev@openjdk.java.net; jdk8u-dev@openjdk.java.net Subject: does C1+CMS miss a storestore membar in jdk8u-shenandoah?
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