[9, 8u40] RFR (XS): 8068915: uncommon trap w/ Reason_speculate_class_check causes performance regression due to continuous deoptimizations

[Vladimir Kozlov]

Okay.

Thanks,
Vladimir K

On 1/22/15 10:17 AM, Vladimir Ivanov wrote:
> Updated version:
> http://cr.openjdk.java.net/~vlivanov/8068915/webrev.01
>
> Added diagnostic message in compilation log.
> Added too_many_recompiles() for null_assert.
>
> Best regards,
> Vladimir Ivanov
>
> On 1/16/15 9:34 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8068915/webrev.00
>> https://bugs.openjdk.java.net/browse/JDK-8068915
>>
>> The fix for 8063137 [1] (just sent out for review) uncovered another
>> issue with deoptimization counts pollution. In some cases, speculative
>> traps can stuck continuously deoptimizing and never reach recompilation.
>> Usually, it ruins performance if it happens.
>>
>> When a speculative guard is considered, Compile::too_many_traps() is
>> consulted to decide whether to add it or not. But, uncommon trap action
>> can be changed to Action_none in GraphKit::uncommon_trap, if
>> Compile::too_many_recompiles() fires.
>>
>> The fix is to (1) forbid changing uncommon trap action under the hood,
>> and (2) consult Compile::too_many_recompiles when adding a speculative
>> guard.
>>
>> The fix is based on 8063137 [2] (uncommon_trap_exact is used).
>>
>> Testing: JPRT, java/lang/invoke tests, nashorn.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8063137
>> [2] http://cr.openjdk.java.net/~vlivanov/8063137/webrev.00/hotspot/