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

[Vladimir Ivanov]

Vladimir,

Thanks for the feedback!

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

> You already have 'result' variable for argument(0), why reread?:
>
> CmpINode(argument(0)
Good point. Fixed.

> Usually IfTrue is the fast path. IGVN will revert that check to have
> that. But it is better to have it in code. Current code looks like
> double negation.
Fixed.

> There is no explanation in changes why false_count never seen (== 0) is
> more important than true_count == 0. The comment says "one of the values".
The code is the following:
     if (false_cnt == 0 || true_cnt == 0) {
       // According to profile, one value has been never seen.
       int expected_val = (false_cnt == 0) ? 1 : 0;

(false_cnt != 0) => (true_cnt == 0).
Do you want me to add additional comment about that?

I chose (false_cnt == 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