On Tue, 29 Apr 2025 09:16:39 GMT, Hamlin Li <m...@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
