java 17 libsvml.so conflict with user app

[David Holmes]

On 26/10/2021 8:16 pm, Maurizio Cimadamore wrote:
> 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 

This library ends up getting loaded unconditionally even just running 
"java -version"! That's a bug in the hotspot "foreign" support code IMO.

David
-----

> 
> 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