RFR: 8368732: RISC-V: Detect support for misaligned vector access via hwprobe [v2]

[Fei Yang]

On Mon, 29 Sep 2025 09:30:20 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> The purpose is to give a consistent view of how the these extensions should be used. That is we only use the value of the extension when it is enabled. Otherwise, we are relying on the default value -1, which doesn't seem safe to me. And it shouldn't be a issue in performance to have this check here. What do you think?
>
> `-1` normally means error/fail/unsuccess, or something similar. The reason that `-1` was chosen as default value should have the same rational here. I wonder if the linux or a C api would choose `-1` to mean pass/success.
> In the case of `AlignVector`, we only enable unaligned vector mem access when `value == MISALIGNED_VECTOR_FAST`, in this sense, w/wo `unaligned_vector.enabled()` produce the exact  same result.
> In this sense, the `unaligned_vector.enabled()` is redundant.
> 
> In another hand, if the default value of a vm option `A` is true and its CPU feature is not enabled (for some reason), we should still set the default value of `A` as `cpu_feature_A.value() !=/== A_enabled_Value`, rather than only set it when it's enabled.
> In this sense, it's safer to always set a VM option's default value based on its value in RVFeatureValue instance.

OK if you prefer that way. I think that should only work for these non-extension hwprobe items. So you might also want to remove the enabled check for other friends like `zicboz_block_size` and `mvendorid` for consistency. But that should go as a separate PR. I just updated this PR removing this check. Please take another look. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27512#discussion_r2387421424