JRuby invokedynamic updates

[Rémi Forax]

Hi Chistian,

On 08/12/2011 11:44 AM, Christian Thalinger wrote:
> On Aug 11, 2011, at 11:07 PM, Charles Oliver Nutter wrote:
>
>> On Wed, Aug 10, 2011 at 11:02 PM, Charles Oliver Nutter
>> <headius at headius.com>  wrote:
>>> I've added bench/bench_fib_complex.rb. This runs the original fib
>>> along with three variations:
>>>
>>> * One that uses constants for the literals 1 and 2 in the code
>>> * One that dispatches to other Ruby methods for the<, -, and + calls
>>> * One that does both
>>>
>>> Performance is perhaps most easily explained by showing the numbers:
>> After talking with Christian I realized that the constant-based
>> versions were not getting fully bound with invokedynamic because they
>> have pre/post logic (specifically, they need to update some
>> thread-local frame state in JRuby). Ignore those results for the
>> moment.
>>
>> There does still seem to be a problem with switchpoints though. I
>> stripped out all but the "additional calls" version and compared
>> switchpoint invalidation with normal.
>>
>>
>> headius at headius-desktop:~/projects/jruby$
>> JAVA_HOME=~/hsx-hotspot/build/linux/jdk-linux-i586/ bin/jruby --server
>> bench/bench_fib_complex.rb 5 35
>> fib with additional calls
>> 9227465
>>   2.180000   0.000000   2.180000 (  2.070000)
>> fib with additional calls
>> 9227465
>>   1.829000   0.000000   1.829000 (  1.829000)
>> fib with additional calls
>> 9227465
>>   1.870000   0.000000   1.870000 (  1.870000)
>> fib with additional calls
>> 9227465
>>   1.642000   0.000000   1.642000 (  1.642000)
>> fib with additional calls
>> 9227465
>>   1.639000   0.000000   1.639000 (  1.639000)
>>
>> headius at headius-desktop:~/projects/jruby$
>> JAVA_HOME=~/hsx-hotspot/build/linux/jdk-linux-i586/ bin/jruby --server
>> -Xinvokedynamic.invocation.switchpoint=true bench/bench_fib_complex.rb
>> 5 35
>> fib with additional calls
>> 9227465
>>   5.951000   0.000000   5.951000 (  5.841000)
>> fib with additional calls
>> 9227465
>>   5.538000   0.000000   5.538000 (  5.538000)
>> fib with additional calls
>> 9227465
>>   5.531000   0.000000   5.531000 (  5.531000)
>> fib with additional calls
>> 9227465
>>   5.503000   0.000000   5.503000 (  5.503000)
>> fib with additional calls
>> 9227465
>>   5.505000   0.000000   5.505000 (  5.505000)
>>
>> My quick look through inlining shows that "plus", "minus", "lt" all
>> inline into fib_ruby3 ok, as do the binops they call. fib_ruby3
>> appears to recursively inline one level. I did not see any obvious
>> failures in inlining, but there's something not right here.
> 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/
>
> 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

I wonder if this patch is not too much.
If a big method is called through an invokedynamic +  method handle
then it will be inlined.

I wonder if it's not better to crawle the method handle tree and
sum up the bytecode size of all method that have a bytecode size
(all the ones that aren't in j.l.invoke).

Rémi