[9] RFR (S): 8074548: Never-taken branches cause repeated deopts in MHs.GWT case (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Mar 17 18:10:42 UTC 2015

Looks good.

Thanks, Vladimir

On 3/17/15 8:59 AM, Vladimir Ivanov wrote:

Updated webrev in place: http://cr.openjdk.java.net/~vlivanov/8074548/webrev.00/

On 3/17/15 4:13 AM, Vladimir Kozlov wrote: Reading an other comment in this method helped to understand what is going on:

// Profile is int[2] where [0] and [1] correspond to false and true value occurrences respectively. May be add comment before next line that result is 0 or 1 and profile is number of each value occurrences: Node* result = argument(0); Done. I think you need to changes PROBNEVER to PROBALWAYS since you swapped condition. But please, verify generated code. You are right. Generated code looks good. Best regards, Vladimir Ivanov

Thanks, Vladimir

On 3/16/15 4:42 PM, Vladimir Ivanov wrote: There is no explanation in changes why falsecount never seen (== 0) is more important than truecount == 0. The comment says "one of the values". The code is the following: if (falsecnt == 0 || truecnt == 0) { // According to profile, one value has been never seen.

That is what confuse me "one value never seen" but truecnt > 0. What does it mean? By "value" I mean boolean value here: "true" or "false". If (falsecnt == 0) or (truecnt == 0), but (falsecnt + truecnt) > 0 (earlier check), then either the value is always "true" or "false" correspondingly. In other words, "false" or "true" (but not both!) has been never observed during profiling. That's what the comment communicates. Best regards, Vladimir Ivanov

Vladimir K int expectedval = (falsecnt == 0) ? 1 : 0; (falsecnt != 0) => (truecnt == 0). Do you want me to add additional comment about that? I chose (falsecnt == 0) because it refers to "always true" case. Best regards, Vladimir Ivanov

Thanks, Vladimir On 3/16/15 11:26 AM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8074548/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8074548 MethodHandleImpl::profileBoolean doesn't update never-taken branch count when hitting a deopt on it. As a result, for rarely taken branches consequent compilations consider them as never-taken and prune them again causing repeated deopts. It severely affects peak performance. The fix is to update MHI::profileBoolean intrinsic to insert a guard and uncommon trap w/ reexecute bit set for never-seen value. Once previously never seen value is encountered, the execution resumes after deopt in MHI::profileBoolean and corresponding count becomes non-zero. The guard doesn't add any additional overhead, since it dominates all value usages and all branches on the same value are eliminated. Testing: java/lang/invoke, nashorn, octane Best regards, Vladimir Ivanov

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

More information about the hotspot-compiler-dev mailing list