RFR: 8343377: Performance regression in reflective invocation of native methods

monk duke at openjdk.org
Thu Nov 21 03:01:18 UTC 2024


On Tue, 19 Nov 2024 14:16:47 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
>
> I tested with the particular test case given in the original test, which is not a strict benchmark; still with the virtual method switched to MH accessor, average time is about 1/10 of before.

Hi @liach,I am the original bug reporter,happy to see the patch.Because of the bug report web can not submit new comment with some web error,I want to tell you new imformation here.
I run some new test and get new result:
1.I confirm Object.hashcode has the same issue.
2.toString() also has a slight decrease in performance,but not as exaggerated as the native methods, about -20%,I don't should is be expected.

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

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2489963193


More information about the core-libs-dev mailing list