On Aug 16, 2011, at 12:19 AM, Charles Oliver Nutter wrote: > On Mon, Aug 15, 2011 at 1:01 PM, Tom Rodriguez <tom.rodrig...@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@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
