On Tue, 15 Sep 2026 07:34:19 GMT, Fei Yang <[email protected]> wrote:
>> Yes, we can create a new JBS for this optimization later. > >> However, a more intuitive way of thinking is that a feature has two distinct >> dimensions: supported (whether CPU/OS support has been detected) and enabled >> (whether the JVM chooses to use it). A supported feature may remain >> disabled, but attempting to enable an unsupported feature should trigger a >> warning and leave it disabled, rather than override capability detection. > > The situation is quite complex here on this CPU platform. Currently, we > mainly rely on the hwprobe linux syscall for hardware feature/extension > detection and option enablement. As I remembered, there are several > considerations. First, the number of extensions is non-trivial. It's not that > feasible for end users to manually select and enable all of them. But they > are still able to disable ones they don't like. The diagnostic options are > still there. Second, it's not easy to say which extensions are not supported. > The ecosystem is still maturing. And you have different kernel versions with > / without hwprobe syscall. The hwprobe syscall is evolving too adding more > extensions as we go. So it could happen that a feature is there, but is not > detected on old kernels. Still the user could enable such ones through these > diagnostic options on the command line. Thanks, that makes sense. I missed the "unknown" state where hardware support exists but the kernel cannot report it. It still feels slightly unsafe to treat "not reported" as "assume supported", but I understand why the diagnostic override can be useful here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32309#discussion_r4021373984
