On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> This reimplements core reflection with method handles. >> >> For `Constructor::newInstance` and `Method::invoke`, the new implementation >> uses `MethodHandle`. For `Field` accessor, the new implementation uses >> `VarHandle`. For the first few invocations of one of these reflective >> methods on a specific reflective object we invoke the corresponding method >> handle directly. After that we spin a dynamic bytecode stub defined in a >> hidden class which loads the target `MethodHandle` or `VarHandle` from its >> class data as a dynamically computed constant. Loading the method handle >> from a constant allows JIT to inline the method-handle invocation in order >> to achieve good performance. >> >> The VM's native reflection methods are needed during early startup, before >> the method-handle mechanism is initialized. That happens soon after >> System::initPhase1 and before System::initPhase2, after which we switch to >> using method handles exclusively. >> >> The core reflection and method handle implementation are updated to handle >> chained caller-sensitive method calls [1] properly. A caller-sensitive >> method can define with a caller-sensitive adapter method that will take an >> additional caller class parameter and the adapter method will be annotated >> with `@CallerSensitiveAdapter` for better auditing. See the detailed >> description from [2]. >> >> Ran tier1-tier8 tests. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8013527 >> [2] >> https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430 > > Mandy Chung has updated the pull request incrementally with one additional > commit since the last revision: > > minor cleanup and more test case. Hi Peter, `VarHandles` are not backed by `LambdaForm`. I did an experiment to change the `FieldAccessor` to use `MethodHandle` instead of `VarHandle` [1] applying on top of your patch. MH customization does help improving the performance. The regression is reduced from 82-85% to 43-52%. Perhaps this is more acceptable and see what @cl4es thinks. baseline Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.instanceFieldConst avgt 10 80.557 ? 0.022 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 73.698 ? 0.458 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 59.393 ? 0.028 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 102.994 ? 0.205 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 67.911 ? 0.061 ns/op plevart's patch: Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.instanceFieldConst avgt 10 42.429 ? 0.016 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 133.405 ? 0.087 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 42.468 ? 0.326 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 188.546 ? 0.073 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 124.686 ? 0.078 ns/op plevart's patch + vh-mh.patch [1] Benchmark Mode Cnt Score Error Units ReflectionSpeedBenchmark.instanceFieldConst avgt 10 42.402 ? 0.022 ns/op ReflectionSpeedBenchmark.instanceFieldVar avgt 10 105.648 ? 0.047 ns/op ReflectionSpeedBenchmark.staticFieldConst avgt 10 42.437 ? 0.033 ns/op ReflectionSpeedBenchmark.staticFieldPoly avgt 10 178.820 ? 0.292 ns/op ReflectionSpeedBenchmark.staticFieldVar avgt 10 102.676 ? 0.081 ns/op [1] http://cr.openjdk.java.net/~mchung/jep416/vh-mh.patch ------------- PR: https://git.openjdk.java.net/jdk/pull/5027
