OSGI, shared class loader and graalvm problem

[holger_hees]

Currently I’m implementing together with @jsjames a python binding using graalpy. It is almost working, except the broken binding reload error. If I unload the binding and reload again, I get the following error.

Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.InternalError: java.lang.UnsatisfiedLinkError: Native Library /Users/jeff/Library/Caches/org.graalvm.polyglot/engine/libtruffleattach/393a4156aea428a

ba9bfd1f6b458df3d1879a5cead397ff970b08a72d43b9185/bin/libtruffleattach.dylib already loaded in another classloader [in thread "Refresh Thread: Equinox Container: 79e5d3d2-e611-40e3-8701-cf5eb1a8e27c”

After I talked to some graalvm devs the told me that the reason could be the usage of different class loaders in osgi. They recommend to use a shared class loader.

Can someone provide some background about this. Do we already use a shared class loader. Or can I control, which one I can use… In the meantime they recommend to disable the loading of native libraries by using the config flag “-Dtruffle.UseFallbackRuntime=true” which prevents loading this. Details can also be found here

@florian-h05 has jsscripting the same problem?

— UPDATE —

The flag “-Dtruffle.UseFallbackRuntime=true” was not successful. It only skipped the part with the " libtruffleattach.so" library. The next problem was related to the lib “libtrufflenfi.so”

The developers remembered that this solution only works with JavaScript and not with Python, because Python uses NFI. The only solution in this case would be to use a shared classloader.

— UPDATE —

I found these graalvm ticket which is not 100% related to our issues, but they talk about to change the osgi class loading behavior. So I want to try to set these ENV var

EXTRA_JAVA_OPTS=“-Dorg.osgi.framework.system.packages.extra=org.graalvm.polyglot”

but this prevents openhab completely to start. I may have replaced an existing property. My understanding was that this is forcing the mention package ‘org.graalvm.polyglot’ to be loaded with the root class loader and then inherited to the bundle class loader.

any osgi experts here, with some suggestions?

[florian-h05 (Florian H.)]

JS Scripting has the same issue, see [jsscripting] Dropping/Updating JAR bundle causes `UnsatisfiedLinkError: Native library already loaded in another classloader` · Issue #18054 · openhab/openhab-addons · GitHub.

It is setting a custom OSGi service loader, no idea what that exactly does though.

As in OSGi, every bundle has its own class loader and the Graal stuff needs to be accessed by both GraalJS and GraalPython, I figured out we might want/need to OSGi-ify GraalVM, so we can share it across multiple add-on bundles and don’t need to bundle it with every single one, also see [jsscripting] Dropping/Updating JAR bundle causes `UnsatisfiedLinkError: Native library already loaded in another classloader` · Issue #18054 · openhab/openhab-addons · GitHub.

Unfortunately, I ran into problems that I cannot solve alone (described in the above issue) and hence asked @wborn for help with OSGi.