> 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Code Format ------------- Changes: - all: https://git.openjdk.org/jdk/pull/32309/files - new: https://git.openjdk.org/jdk/pull/32309/files/771efa6c..3a7ee440 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=32309&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=32309&range=05-06 Stats: 1423 lines in 4 files changed: 0 ins; 1423 del; 0 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
