JRuby invokedynamic updates

Christian Thalinger christian.thalinger at oracle.com
Wed Aug 24 06:50:43 PDT 2011 

On Aug 16, 2011, at 12:19 AM, Charles Oliver Nutter wrote:

> On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:
>> 
>> On Aug 12, 2011, at 4:15 PM, Charles Oliver Nutter wrote:
>>> Well, let me play devil's advocate here: why not just discount MH
>>> chains completely?
>> 
>> It really only to deal with pathologically long chains.  Most method handle chains are pretty simple and should generally just be inlined.  However I could build a chain that included a very large number of calls embedded in it and blindly inlining that could cause the compile to grow too large.  Chains of method handle chains make it worse.  Whatever limit we would pick would be fairly high so that no normal usage would never be cut off.
> 
> I'm not a compiler guy, so I don't know what "too large" means when it
> comes to the compile. Is it:
> 
> * Too complex graph so compilation runs too long?
> * Too big native code so something blows up or crashes?
> * Too big native code so it doesn't fit in cache and runs much slower?
> 
> As long as the limit is suitably high, I think everyone will be happy.
> I can't see any JRuby use involving more than a few dozen adapters for
> the most complex cases, mostly argument juggling and converting.
> 
>>> This probably needs to happen for client mode at the very least. We
>>> probably can't get client to inline invokedynamic, but if it at least
>>> dispatches to a compiled MH chain it would be a lot better than what
>>> it does now (which I think is just execute the chain of handles
>>> as-is...usually very slow).
>> 
>> Client will start to do more inlining in 7u2 but it will still be limited because of the lack of profiling.  Being able to compile them separately would make the whole system more stable performance wise.  I don't know that we can do that for 7u2 though.  Doing it correctly may require more machinery than we have time to build for 7u2.
> 
> My contingency plan is to only turn on invokedynamic when I can see
> we're running on Hotspot C2, and use the old mechanisms when running
> under C1. That is an acceptable trade-off until client mode handles
> invokedynamic/MHs better than it does now.

I have some preliminary results for:

7079673: JSR 292: C1 should inline bytecoded method handle adapters

These numbers are with:

7078382: JSR 292: don't count method handle adapters against inlining budgets

applied (which I currently have out for review).  Without that patch the performance goes back down the toilet.  I think the next single most important thing is to add support for calling bytecoded method handle adapters directly.

intelsdv07:~/mlvm/jruby$ jruby -J-showversion --client bench/bench_fib_complex.rb 5 35
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

normal fib
 11.765000   0.000000  11.765000 ( 11.748000)
 11.765000   0.000000  11.765000 ( 11.765000)
 11.746000   0.000000  11.746000 ( 11.746000)
 11.745000   0.000000  11.745000 ( 11.745000)
 11.702000   0.000000  11.702000 ( 11.702000)
fib with constants
 14.879000   0.000000  14.879000 ( 14.879000)
 14.912000   0.000000  14.912000 ( 14.912000)
 15.255000   0.000000  15.255000 ( 15.255000)
 15.168000   0.000000  15.168000 ( 15.169000)
 15.320000   0.000000  15.320000 ( 15.320000)
fib with additional calls
 25.799000   0.000000  25.799000 ( 25.798000)
 25.705000   0.000000  25.705000 ( 25.705000)
 26.044000   0.000000  26.044000 ( 26.044000)
 26.028000   0.000000  26.028000 ( 26.028000)
 26.351000   0.000000  26.351000 ( 26.351000)
fib with constants and additional calls
 25.053000   0.000000  25.053000 ( 25.053000)
 24.406000   0.000000  24.406000 ( 24.406000)
 24.550000   0.000000  24.550000 ( 24.550000)
 24.478000   0.000000  24.478000 ( 24.478000)
 24.381000   0.000000  24.381000 ( 24.381000)

intelsdv07:~/mlvm/jruby$ jruby -J-showversion --client -Xcompile.invokedynamic=false bench/bench_fib_complex.rb 5 35
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

normal fib
  1.778000   0.000000   1.778000 (  1.724000)
  1.740000   0.000000   1.740000 (  1.740000)
  1.734000   0.000000   1.734000 (  1.734000)
  1.735000   0.000000   1.735000 (  1.736000)
  1.745000   0.000000   1.745000 (  1.745000)
fib with constants
  3.420000   0.000000   3.420000 (  3.420000)
  3.379000   0.000000   3.379000 (  3.379000)
  3.387000   0.000000   3.387000 (  3.387000)
  3.398000   0.000000   3.398000 (  3.398000)
  3.389000   0.000000   3.389000 (  3.389000)
fib with additional calls
  2.953000   0.000000   2.953000 (  2.953000)
  2.973000   0.000000   2.973000 (  2.973000)
  2.974000   0.000000   2.974000 (  2.974000)
  2.977000   0.000000   2.977000 (  2.977000)
  2.979000   0.000000   2.979000 (  2.979000)
fib with constants and additional calls
  4.290000   0.000000   4.290000 (  4.290000)
  4.222000   0.000000   4.222000 (  4.222000)
  4.221000   0.000000   4.221000 (  4.222000)
  4.223000   0.000000   4.223000 (  4.223000)
  4.222000   0.000000   4.222000 (  4.221000)

intelsdv07:~/mlvm/jruby$ jruby -J-showversion --client bench/bench_fib_complex.rb 5 35
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b01)
Java HotSpot(TM) Client VM (build 22.0-b01-internal, mixed mode)

normal fib
  1.072000   0.000000   1.072000 (  1.056000)
  1.059000   0.000000   1.059000 (  1.059000)
  1.042000   0.000000   1.042000 (  1.042000)
  1.043000   0.000000   1.043000 (  1.044000)
  1.048000   0.000000   1.048000 (  1.049000)
fib with constants
  3.178000   0.000000   3.178000 (  3.179000)
  3.036000   0.000000   3.036000 (  3.036000)
  3.056000   0.000000   3.056000 (  3.056000)
  3.052000   0.000000   3.052000 (  3.052000)
  3.052000   0.000000   3.052000 (  3.052000)
fib with additional calls
  1.698000   0.000000   1.698000 (  1.698000)
  1.677000   0.000000   1.677000 (  1.677000)
  1.677000   0.000000   1.677000 (  1.677000)
  1.678000   0.000000   1.678000 (  1.678000)
  1.680000   0.000000   1.680000 (  1.680000)
fib with constants and additional calls
  3.483000   0.000000   3.483000 (  3.483000)
  3.501000   0.000000   3.501000 (  3.501000)
  3.496000   0.000000   3.496000 (  3.496000)
  3.498000   0.000000   3.498000 (  3.498000)
  3.530000   0.000000   3.530000 (  3.530000)

And here is a redblack tree:

intelsdv07:~/mlvm/redblack$ jruby -J-showversion --client bm1.rb
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

18.136
17.942
17.969
17.783
17.916

intelsdv07:~/mlvm/redblack$ jruby -J-showversion --client -Xcompile.invokedynamic=false bm1.rb
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

2.791
2.563
2.587
2.568
2.628

intelsdv07:~/mlvm/redblack$ jruby -J-showversion --client bm1.rb
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b01)
Java HotSpot(TM) Client VM (build 22.0-b01-internal, mixed mode)

3.998
2.278
2.25
2.204
2.193

@Charlie:  Is redblack doing self-verification?

-- Christian

> 
> - Charlie
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

More information about the mlvm-dev mailing list