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@openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to