On Thu, 17 Sep 2026 13:14:33 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 with a new target base due to a merge or > a rebase. The pull request now contains 29 commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8358959 > - RISC-V: Address lgxbslgx's Zalasr code review comments > - Add test test to verify the Zalasr acquire/release instructions > - 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 > - ... and 19 more: https://git.openjdk.org/jdk/compare/0460edfc...da74e1f5
I used a JMH benchmark that comes with OpenJDK, `org.openjdk.bench.vm.compiler.ConstructorBarriers.java`, to observe the performance improvement from this PR. The test environment is a 10M FPGA with physical Zalasr hardware extensions. before this patch: Benchmark Mode Cnt Score Error Units ConstructorBarriers.escaping_finalFinal avgt 3 4356.990 ? 4872.274 ns/op ConstructorBarriers.escaping_finalPlain avgt 3 4357.441 ? 1577.302 ns/op ConstructorBarriers.escaping_finalVolatile avgt 3 6948.905 ? 16242.406 ns/op ConstructorBarriers.escaping_plainFinal avgt 3 3925.632 ? 8806.520 ns/op ConstructorBarriers.escaping_plainPlain avgt 3 5024.004 ? 9549.453 ns/op ConstructorBarriers.escaping_plainVolatile avgt 3 7437.338 ? 2313.666 ns/op ConstructorBarriers.escaping_volatileFinal avgt 3 8403.116 ? 8617.256 ns/op ConstructorBarriers.escaping_volatilePlain avgt 3 8186.508 ? 7484.627 ns/op ConstructorBarriers.escaping_volatileVolatile avgt 3 10657.563 ? 9515.443 ns/op ConstructorBarriers.non_escaping_finalFinal avgt 3 1238.342 ? 122.676 ns/op ConstructorBarriers.non_escaping_finalPlain avgt 3 1248.501 ? 79.321 ns/op ConstructorBarriers.non_escaping_finalVolatile avgt 3 2317.679 ? 38.174 ns/op ConstructorBarriers.non_escaping_plainFinal avgt 3 1233.753 ? 187.689 ns/op ConstructorBarriers.non_escaping_plainPlain avgt 3 1242.682 ? 82.235 ns/op ConstructorBarriers.non_escaping_plainVolatile avgt 3 2382.247 ? 1771.623 ns/op ConstructorBarriers.non_escaping_volatileFinal avgt 3 2334.942 ? 178.572 ns/op ConstructorBarriers.non_escaping_volatilePlain avgt 3 2319.492 ? 89.694 ns/op ConstructorBarriers.non_escaping_volatileVolatile avgt 3 2381.487 ? 1748.670 ns/op after this patch: Benchmark Mode Cnt Score Error Units ConstructorBarriers.escaping_finalFinal avgt 3 4084.098 ? 6095.539 ns/op ConstructorBarriers.escaping_finalPlain avgt 3 3818.386 ? 4782.645 ns/op ConstructorBarriers.escaping_finalVolatile avgt 3 5203.978 ? 4910.253 ns/op ConstructorBarriers.escaping_plainFinal avgt 3 4738.990 ? 8638.579 ns/op ConstructorBarriers.escaping_plainPlain avgt 3 3967.734 ? 3767.787 ns/op ConstructorBarriers.escaping_plainVolatile avgt 3 5455.132 ? 891.534 ns/op ConstructorBarriers.escaping_volatileFinal avgt 3 6363.271 ? 13406.485 ns/op ConstructorBarriers.escaping_volatilePlain avgt 3 5168.250 ? 958.577 ns/op ConstructorBarriers.escaping_volatileVolatile avgt 3 5309.609 ? 3902.733 ns/op ConstructorBarriers.non_escaping_finalFinal avgt 3 726.865 ? 159.505 ns/op ConstructorBarriers.non_escaping_finalPlain avgt 3 687.327 ? 196.826 ns/op ConstructorBarriers.non_escaping_finalVolatile avgt 3 685.619 ? 825.631 ns/op ConstructorBarriers.non_escaping_plainFinal avgt 3 683.387 ? 256.213 ns/op ConstructorBarriers.non_escaping_plainPlain avgt 3 742.581 ? 176.360 ns/op ConstructorBarriers.non_escaping_plainVolatile avgt 3 715.572 ? 768.683 ns/op ConstructorBarriers.non_escaping_volatileFinal avgt 3 690.136 ? 358.478 ns/op ConstructorBarriers.non_escaping_volatilePlain avgt 3 645.175 ? 56.496 ns/op ConstructorBarriers.non_escaping_volatileVolatile avgt 3 702.696 ? 712.550 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/32309#issuecomment-5716056085
