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

[monk]

On Thu, 21 Nov 2024 03:28:29 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
>
> Thanks for the test on `Object.hashCode` and `Thread.currentThread` to confirm my guess.
> 
> For the `toString` test:
> 1. I don't think I will fix it as part of this PR; we will create a new issue for it once we confirm it.
> 2. To reproduce, I think first we will test with JDK 17 and 21. Core reflection reimplementation happened in JDK 18.
> 3. For reliable results, I suggest using the JMH tool https://github.com/openjdk/jmh; there is a gradle plugin for it https://github.com/melix/jmh-gradle-plugin and it has a gradle project example https://github.com/melix/jmh-gradle-plugin/tree/master/samples/simple-java/groovy-dsl, as your raw "setup" and system-time based checks have a lot of disturbance.
> 
>> Because of the bug report web can not submit new comment with some web error
> 
> I am sorry, but OpenJDK infrastructure currently has some known issues; even we are automatically logged out. Thank you for coming to the github PR for comments, @moooonk!

Thank you for your suggestion, @liach 
I reimplement test case project with jmh,if you need to check the source code,see in [https://github.com/moooonk/reflect-test](https://github.com/moooonk/reflect-test)
Now we get more accurate new benchmark result:
JDK17:
Benchmark Mode Cnt Score Error Units
RunBenchmark.cloneCase1 thrpt 5 830871722.632 ± 14902415.558 ops/s
RunBenchmark.cloneCase2 thrpt 5 832256881.789 ± 9305066.153 ops/s
RunBenchmark.cloneCase3 thrpt 5 827842981.397 ± 8629836.251 ops/s
RunBenchmark.hashCodeCase1 thrpt 5 726644716.300 ± 4504879.585 ops/s
RunBenchmark.hashCodeCase2 thrpt 5 726540126.956 ± 7249056.369 ops/s
RunBenchmark.hashCodeCase3 thrpt 5 729054390.940 ± 11904383.303 ops/s
RunBenchmark.toStringCase1 thrpt 5 42906690.075 ± 268508.159 ops/s
RunBenchmark.toStringCase2 thrpt 5 41641490.800 ± 271577.545 ops/s
RunBenchmark.toStringCase3 thrpt 5 41824727.616 ± 440507.690 ops/s

JDK21;
Benchmark Mode Cnt Score Error Units
RunBenchmark.cloneCase1 thrpt 5 8783640.822 ± 46196.518 ops/s
RunBenchmark.cloneCase2 thrpt 5 13045394.145 ± 157121.364 ops/s
RunBenchmark.cloneCase3 thrpt 5 2320020521.800 ± 56423864.542 ops/s
RunBenchmark.hashCodeCase1 thrpt 5 11495229.964 ± 110515.482 ops/s
RunBenchmark.hashCodeCase2 thrpt 5 11488996.620 ± 72449.931 ops/s
RunBenchmark.hashCodeCase3 thrpt 5 1590063332.584 ± 15874384.555 ops/s
RunBenchmark.toStringCase1 thrpt 5 40532553.791 ± 349765.261 ops/s
RunBenchmark.toStringCase2 thrpt 5 40912699.225 ± 339420.788 ops/s
RunBenchmark.toStringCase3 thrpt 5 40991023.028 ± 280145.682 ops/s

I hope this can help you! If need any support just let me know.

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

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