RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK [v3]
Jiangli Zhou
jiangli at openjdk.org
Mon Apr 28 18:57:55 UTC 2025
On Mon, 28 Apr 2025 13:04:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> > 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.
>
> I remember this wasn't quite as elegant on Windows, but I suppose there is already some solution in place to look up symbols that are statically linked into the same executable?
With the current effort for enhancing/completing static JDK support, the system is able to detect if it's running on static using checks like `is_vm_statically_linked/JVM_IsStaticallyLinked/JLI_IsStaticallyLinked`. For example, `os::native_java_library` (https://github.com/openjdk/jdk/blob/2f8448034f28276ad5ac1edfa0fb8650e47d4ffa/src/hotspot/share/runtime/os.cpp#L516) and `load_zip_library` retrieve the `os::get_default_process_handle` without doing `dlopen` (e.g. on Linux) to load the native libraries. For longer term, we can make the solution more coherent/general for handling the various cases in the system.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2836196239
More information about the core-libs-dev
mailing list