JRuby invokedynamic updates

[Tom Rodriguez]

> 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?

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.

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