On Thu, 21 Nov 2024 03:28:29 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 > > 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
