> 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](https://openjdk.org/legal/ai).
Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8358959 - RISC-V: Use register operands for Zalasr access helpers - Code Format - Fix for merge code - Merge branch 'master' into JDK-8358959 # Conflicts: # src/hotspot/cpu/riscv/downcallLinker_riscv.cpp # src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp # src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp - Merge remote-tracking branch 'upstream/master' into JDK-8358959 - Use pipe_serial for g1EncodePAndStoreNVolatile - Fix generate_fast_get_int_field0 not use UseZalasr - RISC-V: Route Zalasr accesses through acquire/release MacroAssembler helpers - Update comment - ... and 4 more: https://git.openjdk.org/jdk/compare/6fca34f9...0dc481e9 ------------- Changes: https://git.openjdk.org/jdk/pull/32309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32309&range=08 Stats: 1372 lines in 23 files changed: 1267 ins; 12 del; 93 mod Patch: https://git.openjdk.org/jdk/pull/32309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/32309/head:pull/32309 PR: https://git.openjdk.org/jdk/pull/32309
