On Thu, 26 Oct 2023 15:02:46 GMT, Jorn Vernee <jver...@openjdk.org> wrote:
>> 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.invo...
>
> Jorn Vernee has updated the pull request incrementally with one additional
> commit since the last revision:
>
> move fallback linker initialization outside of try block
One minor nit but the hotspot changes, aposteri, look good.
@JornVernee please don't forget that all non-trivial (as defined by the dev
guide) hotspot changes require at least 2 reviews and a 24 hour wait before
integration. Thanks.
src/hotspot/share/runtime/jniHandles.cpp line 203:
> 201: }
> 202: } else if (is_local_handle(thread, handle) || is_frame_handle(thread,
> handle)) {
> 203: // Not in global storage. Might be a local handle.
The comment doesn't really make sense after the condition is checked.
-------------
PR Review: https://git.openjdk.org/jdk/pull/16349#pullrequestreview-1701022199
PR Comment: https://git.openjdk.org/jdk/pull/16349#issuecomment-1782316338
PR Review Comment: https://git.openjdk.org/jdk/pull/16349#discussion_r1374088191
