On Tue, 19 Nov 2024 14:16:47 GMT, Chen Liang <li...@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
