<div dir="ltr">On Tue, Feb 4, 2025 at 2:26 AM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br>><br>> Hi Jiangli,<br>><br>> On 4/02/2025 5:42 am, Jiangli Zhou wrote:<br>> > Thanks for the thoughts, Jorn!<br>> ><br>> > On Mon, Feb 3, 2025 at 6:07 AM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com">jorn.vernee@oracle.com</a>> wrote:<br>> ><br>> >> Could you give some examples of the assumptions you're talking about here?<br>> >><br>> ><br>> > One example is test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java.<br>> > When building libatExt, it explicitly links with libjvm.so (e.g. on<br>> > Linux), which becomes a recorded dependency of libatExit.so:<br>> ><br>> > <a href="https://github.com/openjdk/jdk/blob/618c5eb27b4c719afd577b690e6bcb21a45fcb0d/make/test/JtregNativeHotspot.gmk#L883C40-L883C49">https://github.com/openjdk/jdk/blob/618c5eb27b4c719afd577b690e6bcb21a45fcb0d/make/test/JtregNativeHotspot.gmk#L883C40-L883C49</a><br>> > ```<br>> > BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm<br>> > ```<br>><br>> So does this mean that any test (or application) that uses JNI and has<br>> to link to libjvm will need to be modified to work with a statically<br>> linked JDK?<br><br>David, please see my responses in <a href="https://github.com/openjdk/jdk/pull/23431#issuecomment-2634531490">https://github.com/openjdk/jdk/pull/23431#issuecomment-2634531490</a>:<br><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">JNI functions are already dynamically called. E.g. in the same test here:</blockquote><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">    res = (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);</blockquote><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">We don't need to change those at all to work on static-jdk. The existing design of JNI functions can work on both dynamic JDK and static JDK.</blockquote><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">The calls fixed by this PR are the very few exceptions that do not follow the design principle. I do think we should fix them by following the right patterns/conventions. Note LoadJavaVM in JDK code calls these functions 'properly', see jdk/src/java.base/unix/native/libjli/java_md.c.</blockquote><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">So far I've only found this test in hotspot tier1 and libExplicitAttach (AttachTest_id0) in JDK tier1 with the issue.</blockquote><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">@dholmes-ora If we don't go with this change, do you have any other suggestions? One other possible alternative that I can think of is using weak symbols, however I think that's no better.</blockquote><br>and <a href="https://github.com/openjdk/jdk/pull/23431#issuecomment-2634595988">https://github.com/openjdk/jdk/pull/23431#issuecomment-2634595988</a>:<br><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">Also to point it out if it's not clear already, libjvm.so is implementation detail. One cannot safely exist at runtime. The static JDK case is a good example.</blockquote><div><br>Best,<br>Jiangli<div><br>><br>> David<br>> -----<br>><br>> > ```<br>> > $ ldd ./build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib/libatExit.so<br>> > linux-vdso.so.1 (0x00007fb80017c000)<br>> > libjvm.so => (snip)<br>> > ...<br>> > /lib64/ld-linux-x86-64.so.2 (0x00007fb80017e000)<br>> > ```<br>> ><br>> > Runtime linker and loader would resolve and load the dependency<br>> > `libjvm.so` when loading `libatExit.so`. As static-jdk does not<br>> > provide `libjvm.so`, it would fail when running the test using the<br>> > static-jdk. I filed <a href="https://bugs.openjdk.org/browse/JDK-8349178">https://bugs.openjdk.org/browse/JDK-8349178</a>.<br>> ><br>> > The good thing is so far testing only has found just a few such cases<br>> > in Tier1 tests.<br>> ><br>> > Best regards,<br>> > Jiangli<br>></div></div></div>