RFR: 8355698: JDK not supporting sleef could cause exception at runtime after JDK-8353786
Vladimir Ivanov
vlivanov at openjdk.org
Wed Apr 30 19:46:26 UTC 2025
On Tue, 29 Apr 2025 09:16:39 GMT, Hamlin Li <mli at openjdk.org> wrote:
> This behavour was decided in previous PRs https://github.com/openjdk/jdk/pull/20781, https://github.com/openjdk/jdk/pull/21083, https://github.com/openjdk/jdk/pull/21502, and some other uncommited PRs prior to these ones.
Can you point me, please, to the relevant parts of the discussions? I wasn't part of them.
>> Do we really want to complicate things even more by supporting arbitrary subsets of vector math stubs?
> I'm not sure what you mean here, but seems to me the fix is simple, we just not throw exception and allow it fall back to java scalar version, and this behaviour is consitent with previous jdk behaviour. Or can you clarify further?
Both SVML and SLEEF-based vector math native libraries are built and bundled with the JDK. JDK is in full control of their sources and should be able to rely on the exact API they expose.
Such behavior has a number of advantages, in particular:
* exposes bugs (missing entries, naming mismatches between JDK and vector math library);
* enables future evolution towards jextract-based automatic Java API extraction (based on library header files)
API variability complicates things, so should be avoided unless there are compelling reasons to justify it. Can you summarize, please, what's the motivation behind such behavior?
If build platform doesn't fully satisfy library requirements, the library can be excluded. If the library is missing, default (Java) implementations are used.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24914#issuecomment-2840370110
More information about the hotspot-dev
mailing list