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
