That was quick! Thanks a lot for the feedback.
Ok, now we're cracking! Performance has definitely returned, and
actually improved 15-20% beyond my current copy of 8u40. Bravo!
I'd suggest to add pre-8u40 jdk into consideration as well. As part of
LF sharing effort, I spent much time healing performance regressions
caused by heavy bytecode sharing. So, it would be useful to compare
fully customized (pre-8u40) vs heavily shared (8u40/9) implementations.
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.
That would be great!
FWIW, the additional "Per" flags did not appear to help performance,
and actually seemd to degrade it almost back to where 8u40 lies.
It seems the hammer is too large then :-) Ignore them unless you see
severe perf regression (that's usually how JDK-8074551 manifests
itself). I'll let you know once I have a fix.
Best regards,
Vladimir Ivanov
- 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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
