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

[Peter Levart]

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 Mandy,

So, here's the mentioned approach:
https://github.com/plevart/jdk/commit/1a31508b7d73bd9fa40aae845c06b24c3cbcfd16
This is a commit above your changes that I have picked from your branch and squashed as a single commit above current master:
https://github.com/plevart/jdk/commit/a2e4a1f9dad9e6951949ce82af54639ed2da9ddf
I think you could chery-pick the former commit into your branch if you wanted to.

What I have done is mainly removing all code around MHInvoker and VHInvoker and calling the target MethodHandle/VarHandle directly in the XxxAccessors. I also made sure that the path of references going from Method/Constructor/Field via MethodAccessor(s)/ConstructorAccessor(s)/FieldAccessor(s) and to MethodHandle/VarHandle is marked with @Stable. So if the Method/Constructor/Field is found to be constant by JIT, so is its associated MethodHandle/VarHandle. I also "fixed" existing MethodAccessor(s)/ConstructorAccessor(s)/FieldAccessor(s) so that they are safe to be "published" via data-race as the fields holding them in Method/Constructor are no longer volatile (in Field they never have been volatile). In Field I had to make two distinct call-sites for fieldAccessor vs. overrideFieldAccessor in order for JIT to propagate @Stable-ness down the chain.

I then ran the following JMH benchmarks (not included in my variant of patch yet) on jdk16, mandy's variant and peter's variant:
https://gist.github.com/plevart/b9c62c8cac9784e2c6d5f51a6386fa84

The results can be visualized via the following links:
jdk16 vs. mandy: https://jmh.morethan.io/?gists=9219d79a09a805eb39607830270d1513,80203847700b9ab8baeb346a02efc804
jdk16 vs. peter: https://jmh.morethan.io/?gists=9219d79a09a805eb39607830270d1513,b11842fbd48ebbd9234251fded50d52e
mandy vs. peter: https://jmh.morethan.io/?gists=80203847700b9ab8baeb346a02efc804,b11842fbd48ebbd9234251fded50d52e

Comparing mandy vs. peter, there are pros and cons. If Method/Field instance is found to be constant by JIT, peter's variant is a little better (16...36%). It Method/Field is not constant as found by JIT, but still a single instance of Method/Field is invoked in a particular call-site, peter's variant is worse (22...48%). I added another variant called "Poly" (for static methods/fields only, but I think results would be similar for instance too). In this variant a single call-site operates with distinct instances of Method/Field and peter's variant is a little better there (3...11%). The cold-start is a little better for peter's variant too (5%).
I think the "Poly" variants are an important representative of real-world usage. Every usage happens in the real world (Const, Var, Poly), but most applications/frameworks that use reflection and where performance matters (such as JPA, various serialization frameworks, etc.) are generic algorithm(s) that abstract over various runtime types, accessing methods/fields/constructors via call-sites that deal with multiple instances of Mehod/Field/Constructor each.
Top speed is possible with peter's variant and even better than with mandys's variant when each call-site is dealing with single instance of Mehod/Field/Constructor but user has to make such instance a constant for JIT (by accessing it from static final or @Stable field)
I don't know how realistic for real world the "Var" class of invocations is where mandy's variant performs equivalently to "Const" class. Are there real world apps where call-sites deal with single instances of Mehod/Field/Constructor but such instances are not constant for JIT?

Comparing jdk16 vs. peter's variant we see peter's variant performs better in "Const" class (11...67%) and worse for "Var" class (11...46%). For "Poly" variant jdk16 is still better (44%) when accessing fields (nothing can beat Unsafe) but when accessing methods peter's variant is just 3% short of jdk16.

So what do you think? Does increased speed of "Var" class of usages (single Mehod/Field/Constructor instance per call-site but not constant) outweight complexity and total work added by MHInvoker/VHInvoker code generation and class loading?

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

PR: https://git.openjdk.java.net/jdk/pull/5027