Invokedynamic updates for JRuby

[Charles Oliver Nutter]

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
>