JRuby invokedynamic updates

[Rémi Forax]

On 08/12/2011 08:41 PM, Christian Thalinger wrote:
> On Aug 12, 2011, at 8:18 PM, Tom Rodriguez wrote:
>
>>> Well, it's the good old:
>>>
>>> @ 95   java.lang.invoke.MethodHandle::invokeExact (45 bytes)   size>  DesiredMethodLimit
>>>
>>> This seems to be the last recursive call that doesn't get inlined.  Setting MaxRecursiveInlineLevel=0 makes it go faster.  I finally filed (a separate bug to keep this a single change):
>>>
>>> 7078382: JSR 292: don't count method handle adapters against inlining budgets
>>>
>>> The proposed fix is:
>>>
>>> http://cr.openjdk.java.net/~twisti/7078382/
>> I wonder if we need to be slightly more selective than this.  Most method handle chains are relatively small and we shouldn't be penalized for that but they could be arbitrarily large too.  Worst case they just expand into a bunch of call sites I guess so maybe it's not that bad.  Maybe we need an alternate metric for this, like number of call sites in the method handle adapter?
> Yes, using zero is not the best approach but it proved the point.  Number of call sites could be a good metric.
>
>> This wouldn't be so bad if method handle chains could be compiled separately.  I suspect we're going to have to support that eventually.  Doing that would make the performance cliff much smaller I think.
> Exactly.  Today I was thinking about this a lot and did some experiments.  The problem we have right now is that invokedynamic instructions have j.l.i.MethodHandle.invokeExact as callee which is a native method.  Maybe we could store the methodOop of the method handle adapter somewhere (in the constant pool cache?) when we have bytecode for a method handle chain and execute that?

It can also be good to store it into the method handle (if it's possible).
In that case, even a MethodHandle not linked to invokedynamic callsite
can be optimized.

>
> -- Christian

Rémi

>
>> tom
>>
>>> The numbers are now like they should be:
>>>
>>> intelsdv07:~/mlvm/jruby$ jruby --server bench/bench_fib_complex.rb 5 35
>>> fib with additional calls
>>> 0.865000   0.000000   0.865000 (  0.835000)
>>> 0.745000   0.000000   0.745000 (  0.745000)
>>> 0.750000   0.000000   0.750000 (  0.750000)
>>> 0.742000   0.000000   0.742000 (  0.742000)
>>> 0.743000   0.000000   0.743000 (  0.744000)
>>>
>>> intelsdv07:~/mlvm/jruby$ jruby --server -Xinvokedynamic.invocation.switchpoint=true bench/bench_fib_complex.rb 5 35
>>> fib with additional calls
>>> 0.789000   0.000000   0.789000 (  0.759000)
>>> 0.661000   0.000000   0.661000 (  0.661000)
>>> 0.659000   0.000000   0.659000 (  0.660000)
>>> 0.661000   0.000000   0.661000 (  0.661000)
>>> 0.661000   0.000000   0.661000 (  0.661000)
>>>
>>> -- Christian
>>>
>>>> - Charlie
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev