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 > > > Having to upgrade to JNI is a bit sad > > I'm not quite sure what you mean that "upgrades" the library to a "JNI > library"? Nor why this is sad? JNI libraries are more restrictive than non-JNI libraries, as JNI libraries can only be loaded by a single class loader. The lifetime of the class loader is re-used as the lifetime of the library, and tells us when OnLoad and OnUnload should be called. This is in particular not needed in this case, and gets us away from the loaded-by-single-class-loader restricted, but as Maurizio says, making this library a JNI library is probably okay, since this class should always be loaded by the boot loader. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836921541
