Charlie, I found the root cause.
So, the problem is never-taken branches indeed.
The way how branch profiling for GWT (JDK-8063137 [1]) is performed
doesn't work well.
I hoped that profile collection and injection actions can be merged (
MHI.profileBoolean) into single action, but it's not the case. It means
that counter isn't updated when deopt event happens. For rarely taken
branches, it means that the method can be recompiled between 2 rare
events and the application will experience a series of
deopt/recompilation events.
I have to split MHI.propfileBoolean in 2 parts: MHI.attachProfile and
MHI.updateProfile.
MHI.attachProfile will be used as MHI.profileBoolean, but w/o updating
counts. Actual profiling will happen in MHI.updateProfile which will be
called on both branches. So, when deopt happens the very first thing it
does is bump the count.
The other problem is that deopt counts pollution can force GWT method to
be marked as non-compilable. It seems I should go back to explicit hint
for JIT to avoid method profiling (e.g. @DontProfile).
I'm working on the fix for both problems and will file a bug shortly.
Best regards,
Vladimir Ivanov
[1] https://bugs.openjdk.java.net/browse/JDK-8063137
On 2/26/15 9:18 PM, Vladimir Ivanov wrote:
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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
