On Wed, 16 Sep 2026 08:40:38 GMT, Guoxiong Li <[email protected]> wrote:
>> Gui Cao has updated the pull request with a new target base due to a merge >> or a rebase. The pull request now contains 26 commits: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8358959 >> - Update for Axel code review >> - RISC-V: Gate native AtomicAccess Zalasr dispatch on a post-validated flag >> - Code format >> - RISC-V: Zalasr code review followups >> - Apply code review >> - RISC-V: Use Zalasr for the ordered accesses in AtomicAccess >> - Merge remote-tracking branch 'upstream/master' into JDK-8358959 >> - RISC-V: Align C1 volatile load dispatch with AArch64 >> - Merge remote-tracking branch 'upstream/master' into JDK-8358959 >> - ... and 16 more: https://git.openjdk.org/jdk/compare/b0ac803f...bcc84174 > > src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2649: > >> 2647: __ bind(notVolatile); >> 2648: } >> 2649: > > Should we always generate `s{b|h|w|d}.rl` and `l{b|h|w|d}.aq` instructions in > interpreter when `UseZalasr` is true? Then we don't need such additional > check. It could be investigated and done in another PR. Agreed this would remove the extra check, but I'd like to keep it out of this PR — it's a bigger change than it looks. Right now the interpreter's volatile field accesses use the same plain-load/plain-store + explicit membar scheme regardless of UseZalasr (see getfield_or_static/putfield_or_static); volatile_load_leading_fence() only bolts on one extra fence to fix the specific cross-tier interop gap where C2 emits a bare s.rl but the interpreter's default load has no leading fence to pair with it via RVWMO rule 7. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4027859895
