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 Mandy, I'm still looking at this great work and have a few questions that I want to ask upfront. I understand the need for hard-coded specialization as opposed to inserting more MH transformations. You want to squeeze the startup costs as much as possible. But what I would like to understand is the need for MHInvoker and generated implementations of that interface. I can see that by making the target MH a constant in such generated MHInvoker, JVM is able to optimize the MH invocation chain better when JIT kicks-in. So instead of holding the reference to a target MethodHandle in say DirectMethodHandleAccessor, you hold a reference to MHInvoker. You trade constant MH optimization for indirection to a non-constant MHInvoker instance (I see @Stable annotation there, but it would only be effective when the holder MethodAccessor instance was also constant which unfortunately isn't as it is held by a volatile field in Method so even if Method was constant, its MethodAccessor would not be). So my question is whether this trade pays off. I wonder what the performance would be if: - MHInvoker was eliminated - the DirectMethodHandleAccessor just used the target MH directly (via @Stable field) but still using hard-coded specializations - AdaptiveMethodHandleAccessor would not be needed then - the Method had @Stable reference to MethodAccessor instead of volatile (data races are used everywhere so why not for this field too?) I guess you already tried this approach and later added MHInvoker "middleman" to optimize the warmed-up performance. If not, I can try that variant and come up with benchmark results to compare... ------------- PR: https://git.openjdk.java.net/jdk/pull/5027
