On Tue, 15 Sep 2026 06:39:58 GMT, Gui Cao <[email protected]> wrote: >> Hi, This PR emits Zalasr load-acquire/store-release instructions (ISA manual >> Table A.7 mapping) for Java volatile accesses across the interpreter, C1 and >> C2, guarded by the experimental UseZalasr flag. >> >> ### Clarifying the JDK-8358959 concern >> JDK-8358959[1] stalled on one question: JIT code using the A.7 mapping may >> interoperate with native code using the old Table A.6 mapping (clang <= 18), >> and on the seq_cst StoreLoad edge that combination is broken — an A.6 store >> carries no trailing barrier (it expects the reader to pay) and an A.7 l.aq >> carries no leading barrier (it expects the writer's .rl annotation), so >> nobody orders the pair (the ISA manual warns about exactly this pair between >> the two tables [2]). Since the JVM cannot audit every user JNI library, the >> issue looked unresolvable. >> >> Our key observation: this incompatibility is not introduced by Zalasr — it >> already exists today. HotSpot's current volatile scheme is "writer pays" >> (trailing fence w,r on volatile stores, bare volatile loads with no leading >> fence). An old clang JNI library doing a seq_cst store is "reader pays" >> (bare store, no trailing barrier). Cross the two and the StoreLoad edge is >> already unpaid, with no Zalasr instruction involved. >> >> This is also exactly why the RISC-V psABI strengthened the C/C++ seq_cst >> store with a trailing fence (gcc >= 13.3, clang >= 19) and deprecated the >> old mapping as "must not be combined" (Note 3 of the psABI atomics chapter >> [3]): the standard already ruled in favor of writer-pays, i.e. HotSpot's >> side. >> >> Consequently, requiring psABI-toolchain-built native code is a pre-existing >> correctness baseline for the JVM on RISC-V, not a new cost of Zalasr. This >> PR therefore: >> >> 1. gates UseZalasr on the JVM itself being built by a psABI toolchain (gcc >> >= 13.3 / clang >= 19), so libjvm and the bundled native libraries are >> guaranteed compatible with the JIT's A.7 code >> 2. keeps interpreter/C1/C2 volatile accesses mutually compatible (C1 >> volatile loads use l*.aq; interpreter volatile loads gain a leading fence >> when C2 is active, mirroring the AArch64 JDK-8179954[4] treatment). >> >> [1] https://bugs.openjdk.org/browse/JDK-8358959 >> [2] https://docs.riscv.org/reference/isa/v20260120/unpriv/mm-eplan.html >> [3] >> https://riscv-non-isa.github.io/riscv-elf-psabi-doc/#_risc_v_atomics_mappings >> [4] https://bugs.openjdk.org/browse/JDK-8179954 >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy... > > Gui Cao has updated the pull request incrementally with one additional commit > since the last revision: > > RISC-V: Gate native AtomicAccess Zalasr dispatch on a post-validated flag
Hi, Did you run JCstress test on real hardware to verify the basic functionality? I suppose tests on both platforms w/wo Zalasr are needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32309#issuecomment-5676547520
