Invokedynamic updates for JRuby

[Rémi Forax]

My hope is that if you have a special path for +1

   for(x=0; i<array.length;i = i+1) { ... }

the VM can detect that the test that the if i == Integer.MAX_VALUE
should not be done in the loop body but at the end of the loop
(or even been removed).

But for that, we need at least that the escape analysis works
through invokedynamic.

Rémi

On 06/15/2011 05:11 AM, Charles Oliver Nutter wrote:
> Ok, numbers for fib with special paths for +1 -1 +2 and -2...this is
> passing a primitive through invokedynamic, assumes we're calling
> Fixnum always, and does not type-guard anything...so it's faster than
> it ought to be, but it shows what difference the simpler overflow
> guard has:
>
> Normal overflow guard:
>
> ~/projects/jruby ➔ jruby -Xinvokedynamic.fastops=true
> bench/bench_fib_recursive.rb 5 35
> 9227465
>    0.882000   0.000000   0.882000 (  0.829000)
> 9227465
>    0.707000   0.000000   0.707000 (  0.707000)
> 9227465
>    0.708000   0.000000   0.708000 (  0.708000)
> 9227465
>    0.707000   0.000000   0.707000 (  0.707000)
> 9227465
>    0.740000   0.000000   0.740000 (  0.740000)
>
> Specialized guards:
>
> ~/projects/jruby ➔ jruby -Xinvokedynamic.fastops=true
> bench/bench_fib_recursive.rb 5 35
> 9227465
>    0.844000   0.000000   0.844000 (  0.793000)
> 9227465
>    0.673000   0.000000   0.673000 (  0.673000)
> 9227465
>    0.675000   0.000000   0.675000 (  0.675000)
> 9227465
>    0.690000   0.000000   0.690000 (  0.690000)
> 9227465
>    0.686000   0.000000   0.686000 (  0.686000)
>
> Fast opts fully guarded and dispatched through JRuby's special call sites:
>
> ~/projects/jruby ➔ jruby bench/bench_fib_recursive.rb 5 35
> 9227465
>    0.969000   0.000000   0.969000 (  0.923000)
> 9227465
>    0.748000   0.000000   0.748000 (  0.748000)
> 9227465
>    0.751000   0.000000   0.751000 (  0.751000)
> 9227465
>    0.751000   0.000000   0.751000 (  0.750000)
> 9227465
>    0.754000   0.000000   0.754000 (  0.754000)
>
> Non-indy (inline caches):
> ~/projects/jruby ➔ jruby -Xcompile.invokedynamic=false
> bench/bench_fib_recursive.rb 5 35
> 9227465
>    1.143000   0.000000   1.143000 (  1.078000)
> 9227465
>    0.856000   0.000000   0.856000 (  0.856000)
> 9227465
>    0.860000   0.000000   0.860000 (  0.860000)
> 9227465
>    0.865000   0.000000   0.865000 (  0.865000)
> 9227465
>    0.865000   0.000000   0.865000 (  0.865000)
>
> And dynopt:
>
> ~/projects/jruby ➔ jruby -Xcompile.invokedynamic=false
> -Xcompile.dynopt=true bench/bench_fib_recursive.rb 5 35
> 9227465
>    0.905000   0.000000   0.905000 (  0.837000)
> 9227465
>    0.671000   0.000000   0.671000 (  0.671000)
> 9227465
>    0.666000   0.000000   0.666000 (  0.666000)
> 9227465
>    0.670000   0.000000   0.670000 (  0.670000)
> 9227465
>    0.669000   0.000000   0.669000 (  0.669000)
>
> - Charlie
>
> On Tue, Jun 14, 2011 at 8:50 PM, Charles Oliver Nutter
> <headius at headius.com>  wrote:
>> I did take your advice and add paths for +- 1 and 2, but did not see an improvement in perf. That's not to say there wasn't one, but it may be lost in the Fixnum object creation...
>>
>> - Charlie (mobile)
>>
>> On Jun 14, 2011, at 18:33, Rémi Forax<forax at univ-mlv.fr>  wrote:
>>
>>> On 06/14/2011 05:02 PM, Charles Oliver Nutter wrote:
>>>> Disabled (for perf or incompleteness):
>>>> * Math operator invocations with literal fixnum RHS (incomplete: no guards)
>>> I'm working on an example for the cookbook that
>>> allows integers to overflow to BigInteger and
>>> has special paths when a constant is involved.
>>>
>>> The idea is that x + 1 should just test if x equals Integer.MAX_VALUE,
>>> and x+0, 0+x, x- 0 and -1- x need no guard at all
>>> (the last one is due to the way integers are encoded).
>>>
>>> Rémi
>>>
>>> _______________________________________________
>>> 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