java 17 libsvml.so conflict with user app
vitalyd at gmail.com
Tue Oct 26 16:40:37 UTC 2021
On Tue, Oct 26, 2021 at 11:54 AM Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 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
> [0.051s][info][compilation] EnableVectorSupport=true
> [0.051s][info][compilation] EnableVectorReboxing=true
> [0.051s][info][compilation] EnableVectorAggressiveReboxing=true
> [0.051s][info][compilation] UseVectorStubs=true
> WARNING: Using incubator modules: jdk.incubator.vector
> Hello World
> 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.
UseVectorStubs appears to be marked experimental. While we could try that
as a workaround (I take it you're suggesting setting
-XX:+UnlockExperimentalVMOptions -XX:-UseVectorStubs), we don't generally
open up experimental options.
> Magnus, is there anything we can do regarding library loading code.
> Renaming the library file as you suggested and perhaps other aspects?
I think renaming the packaged svml lib and changing its symbol names (e.g.
adding some jdk-specific prefix) would be the most robust solution.
For now, we'll look into either removing the packaged libsvml.so (the
linked code Maurizio showed seems to handle the library missing just fine)
or removing the jdk.incubator.vector module, just to make progress on our
jdk 17 testing.
> 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
> > On Oct 26, 2021, at 7:25 AM, Vitaly Davidovich <vitalyd at gmail.com>
> > 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
> > release?
> >> 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.
> > Thanks
> >> 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
> >>> 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)
> >>> 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
> >>> (__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
More information about the hotspot-runtime-dev