The result of `FindClass` is a local JNI handle (in
`find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
need to wrap the return value of `FindClass` in a global reference when storing
it inside fallbackLinker.c.
While investigating this, I also noticed an existing bug in
`JNIHandles::handle_type`. This method is used from the implementation of
`GetObjectRefType` ([2]), and from the implementation of `-Xcheck:jni` code.
The former specifies that `JNIInvalidRefType` is a valid return value, and the
latter compares the result against `JNIInvalidRefType`. However, if the handle
is not any valid type, the implementation bottoms out in a
`ShouldNotReachHere()`, meaning `JNIHandles::handle_type` can never return
`JNIInvalidRefType`. I've fixed this by letting the enclosing if/else chain
fall through to just returning the default result, which is
`JNIInvalidRefType`. In that case, I observe the expected stack trace when
running with `-Xcheck:jni`. For example:
FATAL ERROR in native method: Bad global or local ref passed to JNI
at
jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base@22-internal/Native
Method)
at
jdk.internal.foreign.abi.fallback.LibFallback.doDowncall(java.base@22-internal/LibFallback.java:94)
at
jdk.internal.foreign.abi.fallback.FallbackLinker.doDowncall(java.base@22-internal/FallbackLinker.java:197)
at
java.lang.invoke.LambdaForm$DMH/0x000001b585008000.invokeStaticInit(java.base@22-internal/LambdaForm$DMH)
at
java.lang.invoke.LambdaForm$MH/0x000001b585029400.invoke(java.base@22-internal/LambdaForm$MH)
at
java.lang.invoke.LambdaForm$MH/0x000001b58502d000.invokeExact_MT(java.base@22-internal/LambdaForm$MH)
at TestUpcallDeopt.payload(TestUpcallDeopt.java:93)
at TestUpcallDeopt.main(TestUpcallDeopt.java:84)
at
java.lang.invoke.LambdaForm$DMH/0x000001b585006800.invokeStatic(java.base@22-internal/LambdaForm$DMH)
at
java.lang.invoke.LambdaForm$MH/0x000001b58502a800.invoke(java.base@22-internal/LambdaForm$MH)
at
java.lang.invoke.Invokers$Holder.invokeExact_MT(java.base@22-internal/Invokers$Holder)
at
jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@22-internal/DirectMethodHandleAccessor.java:154)
at
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@22-internal/DirectMethodHandleAccessor.java:103)
at
java.lang.reflect.Method.invoke(java.base@22-internal/Method.java:580)
at
com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.lang.Thread.runWith(java.base@22-internal/Thread.java:1583)
at java.lang.Thread.run(java.base@22-internal/Thread.java:1570)
(while with the current code, we crash and generate an hs_err file)
Testing: tier 1-5, local run of `jdk_foreign` with fallback linker and
`-Xcheck:jni`
[1]:
https://github.com/openjdk/jdk/blob/6f352740cb5e7c47d226fd4039cfb977c0622488/src/hotspot/share/prims/jvm.cpp#L3548
[2]:
https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#getobjectreftype
-------------
Commit messages:
- bail out when FindClass returns NULL
- add -Xcheck:jni to tests
- use global ref for LibFallback_class
Changes: https://git.openjdk.org/jdk/pull/16349/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16349&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8318737
Stats: 15 lines in 6 files changed: 4 ins; 4 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/16349.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/16349/head:pull/16349
PR: https://git.openjdk.org/jdk/pull/16349
