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

[Vladimir Kozlov]

On 3/16/15 4:11 PM, Vladimir Ivanov wrote:
> 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.

Good.

>
>> 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.

That is what confuse me "one value never seen" but true_cnt > 0. What 
does it mean?

Vladimir K

>        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