java 17 libsvml.so conflict with user app

[Maurizio Cimadamore]

Looking at the code, it seems like the library is loaded whenever the 
"jdk.incubator.foreign" module is added on the command line.

Code loading the library seems to be deep in hotspot:

https://github.com/openjdk/jdk/blob/a8edd1b360d4e5f35aff371a91fda42eeb00d395/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L7834

And the code seems not to be guarded by flag. The only think which 
surrounds it is an ifdef for C2, so I suppose disabling C2 causes the 
library not to be loaded.

But I could be wrong and of course that's not a workaround.

In Panama, for different reasons, on Windows systems we create a library 
which contains an array of function pointers to symbols in 
msvcrt/ucrtbase - this allows us to be relatively agnostic as to whether 
the symbols will be defined in one or the other library. I wonder if the 
vector API should add a similar level of indirection - e.g. have a 
"shim" library which depends on "svml" - but not bundle "svml" with the 
JDK (but this assumes the library can always be found installed in the 
system when needed by C2, which I don't know if it can be relied upon).

Maurizio


On 26/10/2021 00:43, Vitaly Davidovich wrote:
> Hi all,
>
> We're testing some of our code on Java 17 (17.0.1)/linux and hit an issue
> related to libsvml.so.  It seems this library is now part of 17 to support
> the (incubating) Vector API.  We have a java library backed (via JNI) by
> NAG, which itself links against libsvml.so.  The issue arises due to
> java.lang.UnsatisfiedLinkError when our java library is trying to call into
> a NAG function which in turn is looking for a certain symbol from libsvml
> (__svml_exp2_ha_mask in particular).
>
> It looks like the JDK is eagerly loading symbols from its packaged libsvml
> (is there a way to disable that for now?).  That version of the library is
> also in conflict with the one we want to load, as witnessed by the missing
> symbol (there're probably others but we stopped testing at this point).
>
> Is this a known issue/compatibility hazard? Happy to hear thoughts/opinions
> on this and provide further info, if needed.
>
> Thanks