Thanks for the report, Charlie! The regression is caused by never-taken branch pruning [1].
-Djava.lang.invoke.MethodHandle.PROFILE_GWT=false makes the regression go away.
My main suspicion is that recompilations caused by pruned branches can lead to less efficient code. But I have to dig the logs before make any conclusions.
I'll keep you posted about my findings. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8069591 On 2/26/15 2:53 AM, Charles Oliver Nutter wrote:
I'm finally at home with a working machine so I can follow up on some VM Summit to-dos. Vladimir wanted me to test out jdk9 hs-comp, which has all his latest work on method handles. I wish I could report that performance looks great, but it doesn't. Here's timing (in s) of our red/black benchmark on JRuby 1.7.19, first on the latest (as of today) 8u40 snapshot build and then on a minutes-old jdk9 hs-comp build: ~/projects/jruby $ (pickjdk 4 ; rvm jruby-1.7.19 do ruby -Xcompile.invokedynamic=true ../rubybench/time/bench_red_black.rb 10) New JDK: jdk1.8.0_40.jdk 5.206 2.497 0.69 0.703 0.72 0.645 0.698 0.673 0.685 0.67 ~/projects/jruby $ (pickjdk 5 ; rvm jruby-1.7.19 do ruby -Xcompile.invokedynamic=true ../rubybench/time/bench_red_black.rb 10) New JDK: jdk1.9_hs-comp 5.048 3.773 1.836 1.474 1.366 1.394 1.249 1.399 1.352 1.346 Perf is just about 2x slower on jdk9 hs-comp. I tried out a few other benchmarks, which don't seem to have as much variation: * recursive fib(35): equal perf * mandelbrot: jdk8u40 5% faster * protobuf: jdk9 5% faster The benchmarks are in jruby/rubybench on Github. JRuby 1.7.19 can be grabbed from jruby.org or built from jruby/jruby (see BUILDING.md). Looking forward to helping improve this :-) - 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
