MethodHandle lookup&invocation performance

[Rémi Forax]

On 07/10/2011 10:14 AM, Alexander Turner wrote:
> John,
>
> Thanks for your fascinating reply. I would just like to clarify something:
>
> "
> Another use case which benefits from this particular optimization
> trick is "static final" method handles.  I.e., if you want to get
> invokedynamic-like performance in plain Java code, consider doing your
> work by invoking MH constants.  This means your bootstrap logic has to
> run in the static initializer of the class containing the constants,
> which is less flexible (more eager).  But it's an option.
> "
>
> Is what you are saying here that making a method handle final static
> will bring invoke performance closer to invokeExact because the
> matching logic only happens once. IE the handle cannot be repatched? I
> am not sure I fully understand this because (as I understand it)
> making a field final does not do change the way fields in the
> reference graph below the field behave. Does a mh 'know' is it final
> and so not attempt to mutate itself or anything to which it refers?

Currently the JIT tries to replace method handle calls
by a direct call (or chain of calls) to after inline them.
This occurs if the method handle is the target of a CallSite
of an invokedynamic, if the method handle is stored
in a final static field or if the method handle is a constant
method handle loaded by a LDC.

Basically, it works if the method handle is reachable from a static root.

Now, if the method handle is reachable from a static root,
them JIT knows its type (its method type) so because
   mh.invoke(args) <=> mh.asType(methodType(args)).invokeExact(args)
the JIT can fully inline mh.invoke(args).

> On another note - it is great to keep hearing that so much work on
> performance is in the pipeline!
>
> Best wishes - AJ

cheers,
Rémi