On Wed, 16 Sep 2026 07:01:19 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/gc/shenandoah/shenandoahBarrierSetAssembler_riscv.cpp 
> line 603:
> 
>> 601:           "acquire path requires address to be base-only");
>> 602:       __ lw_aq(dst, src.base());
>> 603:       __ zext(dst, dst, 32);
> 
> Is `src.offset` always 0? What about using `la` to get the address?

The `indirect` operand used by the `*_volatile_shenandoah` instructs (as 
opposed to the general `memory` operand used by the non-volatile ones) is 
structurally base-only, so `src.offset()` is always 0 by construction here — 
there's no case where a non-zero displacement can reach this path, so 
materializing via `la` isn't needed. Kept the `assert` to document that 
invariant.

> src/hotspot/cpu/riscv/gc/shenandoah/shenandoah_riscv.ad line 215:
> 
>> 213:         /* is_volatile = */ true);
>> 214:   %}
>> 215:   ins_cost(4 * STORE_COST);
> 
> According to the costs of other instructions, should the cost here be 
> `VOLATILE_REF_COST` or `VOLATILE_REF_COST + STORE_COST`?

Fixed.

> src/hotspot/cpu/riscv/gc/z/z_riscv.ad line 162:
> 
>> 160:   format %{ "sd.rl  $mem, $src\t# ptr, #@zStorePVolatile" %}
>> 161:   ins_encode %{
>> 162:     guarantee($mem$$disp == 0, "impossible encoding");
> 
> A problem similar to shenandoah GC: is the displacement always 0?

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4027271146
PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4027242905
PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4027276062

Reply via email to