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