RFR: 8368366: RISC-V: AlignVector is mistakenly set to AvoidUnalignedAccesses

Robbin Ehn rehn at openjdk.org
Tue Sep 23 10:42:06 UTC 2025


On Tue, 23 Sep 2025 07:21:47 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please consider this small change fixing setting of `AlignVector` flag on RISC-V.
> 
> According to the latest RISC-V linux hardware probing syscall [1], the performance of misaligned memory accesses
> has been divided into two cases: `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF` and `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF`
> for scalar and vector respectively. And `RISCV_HWPROBE_KEY_CPUPERF_0` is now deprecated and it returns similar values
> to `RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`.
> 
> Previously, we use `RISCV_HWPROBE_KEY_CPUPERF_0` to detect support for misaligned memory accesses and reflect the result
> on these VM flags: `AvoidUnalignedAccesses`, `UseUnalignedAccesses` and `AlignVector`. But it doesn't seem correct to update
> `AlignVector` according to this value. And this is causing issues on RISC-V hardwares which have fast misaligned accesses only
> for the scalar case. I witnessed SIGBUG error on these hardwares when doing vector misaligned accesses.
> 
> So we should align AlignVector with `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` instead. This patch just reverts the previous
> setting of AlignVector and just let it have the default value which is true. I will try to add detection in a separate PR
> for `RISCV_HWPROBE_KEY_MISALIGNED_VECTOR_PERF` and update `AlignVector` accordingly.
> 
> [1] https://docs.kernel.org/arch/riscv/hwprobe.html

Yes, thanks, I think you are on the right track.

But an additional thing: if user sets "-XX:-UseUnalignedAccesses" I think that should be enought to stop all of them all. Also I'm doubt ful of the usefulness of Avoid flag.
I don't see any case where I would have Avoid = false but also UseUnAl= false.
Right now I always use Avoid = !UseUnal.

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

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27445#pullrequestreview-3257314698


More information about the hotspot-dev mailing list