Jtreg tests with JNI native code on static JDK

[Jiangli Zhou]

On Tue, Feb 4, 2025 at 2:26 AM David Holmes <david.holmes at oracle.com> wrote:
>
> Hi Jiangli,
>
> On 4/02/2025 5:42 am, Jiangli Zhou wrote:
> > Thanks for the thoughts, Jorn!
> >
> > On Mon, Feb 3, 2025 at 6:07 AM Jorn Vernee <jorn.vernee at oracle.com>
wrote:
> >
> >> Could you give some examples of the assumptions you're talking about
here?
> >>
> >
> > One example is test/hotspot/jtreg/runtime/jni/atExit/TestAtExit.java.
> > When building libatExt, it explicitly links with libjvm.so (e.g. on
> > Linux), which becomes a recorded dependency of libatExit.so:
> >
> >
https://github.com/openjdk/jdk/blob/618c5eb27b4c719afd577b690e6bcb21a45fcb0d/make/test/JtregNativeHotspot.gmk#L883C40-L883C49
> > ```
> > BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libatExit := java.base:libjvm
> > ```
>
> So does this mean that any test (or application) that uses JNI and has
> to link to libjvm will need to be modified to work with a statically
> linked JDK?

David, please see my responses in
https://github.com/openjdk/jdk/pull/23431#issuecomment-2634531490:

JNI functions are already dynamically called. E.g. in the same test here:


    res = (*jvm)->AttachCurrentThread(jvm, (void **)&env, NULL);


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.


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.


So far I've only found this test in hotspot tier1 and libExplicitAttach
(AttachTest_id0) in JDK tier1 with the issue.


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


and https://github.com/openjdk/jdk/pull/23431#issuecomment-2634595988:

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.


Best,
Jiangli

>
> David
> -----
>
> > ```
> > $ ldd
./build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib/libatExit.so
> > linux-vdso.so.1 (0x00007fb80017c000)
> > libjvm.so => (snip)
> > ...
> > /lib64/ld-linux-x86-64.so.2 (0x00007fb80017e000)
> > ```
> >
> > Runtime linker and loader would resolve and load the dependency
> > `libjvm.so` when loading `libatExit.so`. As static-jdk does not
> > provide `libjvm.so`, it would fail when running the test using the
> > static-jdk. I filed https://bugs.openjdk.org/browse/JDK-8349178.
> >
> > The good thing is so far testing only has found just a few such cases
> > in Tier1 tests.
> >
> > Best regards,
> > Jiangli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20250204/de1c02a9/attachment-0001.htm>