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
src/hotspot/os_cpu/linux_riscv/atomicAccess_linux_riscv.hpp line 285:
> 283: T operator()(const volatile T* p) const {
> 284: STATIC_ASSERT(byte_size == sizeof(T));
> 285: STATIC_ASSERT(byte_size == 1 || byte_size == 2 || byte_size == 4 ||
> byte_size == 8);
Removal of the STATIC_ASSERT macro is in flight, JDK-8392412 (#32883).
Suggestion:
static_assert(byte_size == sizeof(T));
static_assert(byte_size == 1 || byte_size == 2 || byte_size == 4 ||
byte_size == 8);
src/hotspot/os_cpu/linux_riscv/atomicAccess_linux_riscv.hpp line 305:
> 303: void operator()(volatile T* p, T v) const {
> 304: STATIC_ASSERT(byte_size == sizeof(T));
> 305: STATIC_ASSERT(byte_size == 1 || byte_size == 2 || byte_size == 4 ||
> byte_size == 8);
Removal of the STATIC_ASSERT macro is in flight, JDK-8392412 (#32883).
Suggestion:
static_assert(byte_size == sizeof(T));
static_assert(byte_size == 1 || byte_size == 2 || byte_size == 4 ||
byte_size == 8);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4017627729
PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4017630350
