RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

[Mandy Chung]

On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung <mchung at 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