RFR: 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS [v4]

[Robbin Ehn]

On Wed, 8 Oct 2025 06:46:56 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> But why is not vector size/length called: `VM_Version::non_ext::rvv_vlen()` or similar ? Should it ?
>> 
>> I think this should be in another pr.
>> 
>>> Should VM_Version::non_ext and VM_Version::ext be private, so we create a public: VM_Version::ziboz_block_size() ?
>> 
>> If you prefer `VM_Version::ziboz_block_size` as the interface, then I don't think it's necessary to have `VM_Version::non_ext` and `VM_Version::ext` in the implemention.
>> 
>>> I added: `static bool supports_fencei_barrier() { return ext_Zifencei.enabled(); }`
>>> Was this wrong? Should I have used `VM_Version::ext_Zifencei.enabled()` in MASM ?
>>> Can we agree to one consistent way?
>> 
>> As mentioned above, I think this should be in another pr: a consistent interface of VM_Version.
>
> That reminds me of a previous discussion about non-extension features [1].
> It doesn't seem to be necessary to have a `enabled()` check for non-extension features like `zicboz_block_size`, `mvendorid`, etc. So we might want to remove this check and give these features a default value (maybe -1 as suggested by @Hamlin-Li).
> 
> This is just like how the global flags are used. It will have a valid value if it could be detected from hwprobe interface at JVM startup. Hopefully, that will simplify the use sites of them a bit making it more consistent. In this repect, it works for me if we keep using the current naming, like `VM_Version::zicboz_block_size.value()`.
> 
> [1] https://github.com/openjdk/jdk/pull/27512#discussion_r2387421424

I don't have strong opinions except can we please make it as consistent as possible and make the actual useages (masm/stubs/instrinsic/ad) easy to read/review.
If you say this PR is on that part of such road-map, please go ahead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27562#discussion_r2412764993