On Mon, 28 Apr 2025 08:30:43 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> Jiangli Zhou has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into >> JDK-8355080 >> - Address henryjen@ comment: >> - Remove '#include <jni.h>'. > > The changes here look good. Essentially, if `syslookup` is statically linked, > trying to do a `dlopen` on it will fail, as the shared library for it doesn't > exist. For this reason, this PR seems to "upgrade" syslookup to a JNI > library. The presence of the `JNI_OnLoad_syslookup` is then used, as per [JEP > 178](https://openjdk.org/jeps/178) to determine whether `syslookup` is a > "builtin" library -- that is, a library for which no dynamic linking should > occur. > > The loaded library is associated with the boot classloader. This could be > problematic, in principle. However, since the requests to `loadLibrary` also > come from the boot loader (they are from the `SystemLookup` class) it all > works out ok. > > Having to upgrade to JNI is a bit sad -- although I get that it is required > as a workaround for now. For the longer term I'd prefer a better way to > integrate static lookups in the FFM API. For instance, all `JNI::loadLibrary` > does when it comes to static libraries is to return the so called "process > handle" -- e.g. a handle to the running process (the JVM). If there was a way > to retrieve such a handle (e.g. via a dedicated `SymbolLookup` factory) it > would be possible to avoid the JNI dance: just get the process symbol lookup, > and look for statically linked symbols in there. @mcimadamore @JornVernee Thanks for the in-depth thoughts and reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836201103
