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

[Peter Levart]

On Tue, 21 Sep 2021 15:06:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for each instance of Method/Field does not help at all.
> 
> The added indirection in the "Poly" test might cause the code to fall off the inlining cliff, so that any constant folding becomes unlikely to happen. I agree that this might be closer to what happens in a real app, and as a data point it does show that the MHInvoker/VHInvoker optimizations might have been misguided.

It is not the added indirection (I can add an indirection in the "Var" case too and benchmark would not change), but the variation of Method/Field instances used at the same call-site. When there is only one instance ("Var" case), delegating invocation of a MH to a MHInvoker somehow optimizes speculatively with a guard that just checks that the same MHInvoker class is used each time and further code is generated with constant MH.
Such speculative optimization does not happen with non-constant MHs unfortunately despite the fact that there is only one MH instance.
But in "Poly" case, generated MHInvoker classes don't help as there are multiple such classes and the speculative optimization falls apart (or is never even tried).

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

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