Ok, now we're cracking! Performance has definitely returned, and actually improved 15-20% beyond my current copy of 8u40. Bravo!
I will try testing several other benchmarks, and perhaps set up a machine to do the big perf regression suite the JRuby+Truffle guys made for us. FWIW, the additional "Per" flags did not appear to help performance, and actually seemd to degrade it almost back to where 8u40 lies. - Charlie On Fri, Mar 6, 2015 at 7:06 AM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote: > John, > > You are absolutely right. I should've spent more time exploring the code > than writing emails :-) > > Here's the fix: > http://cr.openjdk.java.net/~vlivanov/8074548/webrev.00/ > > Charlie, I'd love to hear your feedback on it. It fixes the regression on > bench_red_black.rb for me. > > Also, please, try -XX:PerBytecodeRecompilationCutoff=-1 > -XX:PerMethodRecompilationCutoff=-1 (to workaround another problem I spotted > [1]). > > On 3/4/15 5:16 AM, John Rose wrote: >> >> On Mar 3, 2015, at 3:21 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> >> wrote: >>> >>> >>> Ah, I see now. >>> >>> You suggest to conditionally insert uncommon trap in MHI.profileBoolean >>> when a count == 0, right? >>> >>> Won't we end up with 2 checks if VM can't fold them (e.g. some action in >>> between)? >> >> >> Maybe; that's the weak point of the idea. The VM *does* fold many >> dominating ifs, as you know. >> >> But, if the profileBoolean really traps on one branch, then it can return >> a *constant* value, can't it? >> >> After that, the cmps and ifs will fold up. > > Brilliant idea! I think JIT can find that out itself, but additional help > always useful. > > The real weak point IMO is that we need to keep MHI.profileBoolean intrinsic > and never-taken branch pruning logic during parsing (in parse2.cpp) to keep > in sync. Otherwise, if VM starts to prune rarely taken branches at some > point, we can end up in the same situation. > > Best regards, > Vladimir Ivanov > > [1] https://bugs.openjdk.java.net/browse/JDK-8074551 > > _______________________________________________ > 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
