RFR: 8343377: Performance regression in reflective invocation of native methods [v2]

[Mandy Chung]

On Wed, 27 Nov 2024 01:04:06 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
>> 
>> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
>> 
>> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
>> 
>> Testing: tier 1-5 green
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Review comments
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/reflect-native-slow
>  - Better comments
>  - 8343377: Performance regression in reflective invocation of native methods

Marked as reviewed by mchung (Reviewer).

src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 376:

> 374:         // bit set, which verifies that the last parameter of the member must be
> 375:         // an array type.  Such restriction does not exist in core reflection
> 376:         // and the JVM.  Fall back to use the native implementation instead.

Suggestion:

        // For members with ACC_VARARGS bit set, MethodHandles produced by lookup
        // always have variable arity set and hence the last parameter of the member 
        // must be an array type.  Such restriction does not exist in core reflection
        // and the JVM.  Fall back to use the native implementation instead.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22169#pullrequestreview-2473723428
PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1866489642