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

[Alan Bateman]

On Tue, 4 Feb 2025 17:17:17 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.
>
> Also to point it out if it's not clear already, `libjvm.so` is implementation detail. One cannot safely that exists at runtime. The static JDK case is a good example.

> @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!

A custom launcher will typically link to libjvm or use dlopen/dlym to get to JNI_CreateJavaVM. A static build isn't really suitable for custom launchers (or anything that embeds a VM).

So I think the changes to the test are okay if we really want to run this test with a static build. An alternative is to have the tests that use JNI_CreateJavaVM to not be selected. At some point I suspect we'll need to add a property to jtreg-ext/requires/VMProps.java for these builds anyway.

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

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