RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]
mchung at openjdk.java.net
Tue Sep 21 16:29:35 UTC 2021
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  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 .
>> Ran tier1-tier8 tests.
>>  https://bugs.openjdk.java.net/browse/JDK-8013527
>>  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.
> On balance I think removing class-spinning might mean a better overall story w.r.t. footprint and maintainability.
> So I think I'm in favor of simplifying and filing a follow-up to try and win back some of the performance we might be losing on corner-case micros without the custom class spinning.
Great! I'll update the PR with Peter's patch + vh2mh with removal of StaticFieldAccessor/InstanceFieldAccessor inner classes  (no significant performance difference between  and ).
> I wish MethodHandles obtained by unreflectGetter/unreflectSetter could be less sensitive to where they are read from (constant vs. not-constant) and optimize better in non-constant case. I think we should search in this direction... to make MethodHandles obtained by unreflectGetter/unreflectSetter more optimal in non-constant case.
Yup, that's what the performance opportunity we should explore to improve MH/VH that will benefit all clients of MH/VH as well as core reflection.
More information about the core-libs-dev