RFR: 8349178: runtime/jni/atExit/TestAtExit.java should be supported on static JDK

[David Holmes]

On Tue, 4 Feb 2025 01:10:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review runtime/jni/atExit/TestAtExit.java test change:
> 
> - Remove `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm`. Don't explicitly link with libjvm, because it adds libjvm.so as a recorded dependency to libatExit.so (on Linux for example). That requires libjvm.so must be resolved and loaded successfully when libatExit.so is loaded. The static JDK (e.g. static-jdk image) does not provide a libjvm.so for runtime usage.
> - Instead of calling the following functions directly in libatExit.c, change to look up the functions and calls them using the retrieved function addresses:
>   - JNI_GetDefaultJavaVMInitArgs
>   - JNI_GetCreatedJavaVMs
>   - JNI_CreateJavaVM
> 
> On Linux (and similar) platform, there is no need to call `dlopen` for libjvm in libatExit.c explicitly, because the VM must already be loaded by the time when the libatExit native code is executed. Using `RTLD_DEFAULT` can "find symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag" (see https://man7.org/linux/man-pages/man3/dlsym.3.html).  https://github.com/openjdk/jdk/blob/9b49597244f898400222cfc252f50a2401ca3e2f/src/java.base/unix/native/libjli/java_md.c#L533 is where we `dlopen` libjvm with `RTLD_GLOBAL` for unix platform.
> 
> For Windows platform, I added Windows specific code to get the loaded `jvm.dll` first. If it can't find loaded `jvm.dll`, it then get the handle of the executable running the current process. The returned handle is used for finding the function addresses. 
> 
> TestAtExit passes with https://github.com/jianglizhou/jdk/actions/runs/13124407248/job/36619759000. TestAtExit also pass on static-jdk with my local jtreg run.

@jianglizhou  I will be brutally honest and say that I do not like this at all. Does this mean all JNI using tests/applications have to becoded differently to be used with a static JDK? I find it somewhat ironic that to work with a _static_ JDK we have to rewrite the test to perform a _dynamic_ lookup!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23431#issuecomment-2633523332