Lost perf between 8u40 and 9 hs-comp

[Vladimir Ivanov]

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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev