On Tue, 4 Feb 2025 17:17:17 GMT, Jiangli Zhou <jian...@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
