Inlining of MethodHandles chain possible/planned?

[Rémi Forax]

On 05/18/2011 06:44 PM, Charles Oliver Nutter wrote:
> On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim<sjachim at gmail.com>  wrote:
>> I have to questions to you guys about possible (and planned) JIT
>> optimizations for MethodHandles.
>> 1. Assuming that there will be a chain of MH's:
>>        mh1(invoker) ->  mh2 ->  aMethod()
>>     and there will be no other references to mh2. Will JIT/GC be able to
>> optimize unneeded mh2 and put into callsites a direct call to aMethod?
> Yes. The current JDK builds should already do this for most MH types,
> and others are landing every day.
>
>> 2. Assuming second situation:
>>    mh1(dynamicInvoker() product) ->  MutableCallSite ->  mh2(constant()
>> product) ->  integer constant
>> After calculating the constant value and doing setTarget() there will be no
>> longer any other references to MCS and mh2, so MCS is effectively
>> immutable. Will they get optimized away and/or garbage collected?
>> This could be useful to implement efficient lazy initialized data
>> structures. The call site cannot be ConstantCallSite, becouse the value is
>> calculated in runtime by a non static methods...
>> I think this is similar problem to what Headius described here recently.
>> Thanks,
> As Rémi replied, ideally there should be no cost from having a
> MutableCallSite rather than a ConstantCallSite. However I believe with
> Christian was inspecting JRuby+indy assembly output, there's still a
> guard emitted for each MutableCallSite. He said he thought this would
> go away eventually and be replaced with an external deoptimization
> trigger.
>
> As for dynamicInvoker to MutableCallSite...I'm not sure if that will
> inline or not. In theory it seems like it should (and it would sure be
> nice) but I'm not sure if it does right now.

It's not inlined, and it's hard to do.

There are 4 cases that are easy to inline:
- the method handle is a target of an invokedynamic
- the method handle is a value bound to another method handle
   using bindTo or insertArguments
- the method handle is a static final field
- the method handle is a constant method handle (loaded with an LDC)
   and the LDC and the invoke* are in the same inline blob.

All others are hard because the value of the method handle is not 
statically known
i.e the method handle cannot be considered as constant.

Currently, the backport only optimize the first case because it doesn't 
do any
constant propagation analysis that are required for case 3 and 4, it also
doesn't optimize case 2 but should, I've just forgotten this case.

Hotspot does constant propagation, so should do all the cases.

Free callsites, i.e callsites that are not linked to a specific 
invokedynamic
are not optimized because there are not a static root.
So method handle doesn't help a lot to implement lazy evaluation a la 
scheme.

> - Charlie
>
>> Szymon

Rémi