More performance explorations

[Charles Oliver Nutter]

On Thu, May 26, 2011 at 8:40 PM, Charles Oliver Nutter
<headius at headius.com> wrote:
> dynopt is interesting for comparison:
>
> ~/projects/jruby ➔ jruby --server -J-d32 -Xjit.threshold=2
> -Xcompile.invokedynamic=false -Xcompile.dynopt=true
> -Xinvokedynamic.constants=false
> bench/language/bench_method_dispatch_only.rb 10
> Test ruby method: 1000k loops calling self's foo 10 times
>  0.617000   0.000000   0.617000 (  0.541000)
>  0.096000   0.000000   0.096000 (  0.095000)
>  0.066000   0.000000   0.066000 (  0.067000)
>  0.053000   0.000000   0.053000 (  0.054000)
>  0.053000   0.000000   0.053000 (  0.053000)
>  0.055000   0.000000   0.055000 (  0.055000)
>  0.047000   0.000000   0.047000 (  0.047000)
>  0.054000   0.000000   0.054000 (  0.054000)
>  0.048000   0.000000   0.048000 (  0.048000)
>  0.047000   0.000000   0.047000 (  0.047000)

Ok, I revisited my dynopt logic, and one reason this may be so much
faster is that it doesn't actually do the call; the dynopt compilation
sees that the target call just returns self and instead of making the
call it just loads the receiver of the foo call. This still qualifies
as an ideal case; there's no other logic in the "foo" body except an
aload(2) and return, but invokedynamic isn't able to inline it well
enough to eliminate that completely.

foo method's bytecode:

*** Dumping rubyjit/foo_8FAEAAFF427D3481EFD428A515F0C11EBB95F210.__file__ ***
   L0
   L1
    LINENUMBER 4 L1
    ALOAD 2
    ARETURN
   L2
  @Lorg/jruby/anno/JRubyMethod;(name="__file__", frame=true,
required=0, optional=0, rest=-1)

dynopt does still emit the serial number guard and an IC path for the
failure case. It just doesn't do the invoke of foo.

- Charlie