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

[Doerr, Martin]

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 at openjdk.java.net> On Behalf Of Liu
> Xin
> Sent: Donnerstag, 12. Dezember 2019 08:40
> To: aarch64-port-dev at openjdk.java.net; ppc-aix-port-
> dev at openjdk.java.net; jdk8u-dev at 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