java 17 libsvml.so conflict with user app
paul.sandoz at oracle.com
Tue Oct 26 15:54:45 UTC 2021
The Vector API is only enabled when the jdk.incibator.vector module is installed in the image and is visible. If the module is not installed then the svml library will not be present. That is one possible work around.
If you run a simple program with logging we should see:
$java --add-modules=jdk.incubator.vector -Xlog:compilation:stdout A
WARNING: Using incubator modules: jdk.incubator.vector
The code Maurizio linked to is not guarded by the flag UseVectorStubs. I think that is an issue and you should be able to use that flag at least as a work around. I will explore that.
Magnus, is there anything we can do regarding library loading code. Renaming the library file as you suggested and perhaps other aspects?
Intel contributed the SVML assembly source files to the source code base. That was a compromise given the original nature of the sources and their license.
> On Oct 26, 2021, at 7:25 AM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> Hi Maurizio,
> On Tue, Oct 26, 2021 at 6:16 AM Maurizio Cimadamore <
> maurizio.cimadamore at oracle.com> 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:
> Thanks for the code pointer!
>> 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.
> As I mentioned in my reply to Magnus, would it make sense to introduce a
> JVM option to skip loading libsvml/Vector API support for (say a 17.0.2
>> 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).
> It looks like
> defines the various assembly routines making up the libsvml packaged with
> the JDK. Could these perhaps be built up by C2's MacroAssembler instead?
> i.e. rather than loading them from a shared lib, have C2 generate the
> assembly (and stub routines) on-the-fly.
>> 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
>>> 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
>>> 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
>>> (is there a way to disable that for now?). That version of the library
>>> also in conflict with the one we want to load, as witnessed by the
>>> symbol (there're probably others but we stopped testing at this point).
>>> Is this a known issue/compatibility hazard? Happy to hear
>>> on this and provide further info, if needed.
More information about the hotspot-runtime-dev