Re: RFR:8243615 Continuous deoptimizations with Reason=unstable_if and Action=none

[Wang Zhuo(Zhuoren)]

Hi Tobias,
Theoretically speaking other optimizations, with Action_maybe_recompile or Action_reinterpret, can be affected, because in uncommon_trap, Action_maybe_recompile and Action_reinterpret will be changed to Action_none if too many recompiles happened. 
While I have only met this issue with Reason_unstable_if so far.


Regards,
Zhuoren


------------------------------------------------------------------
From:Tobias Hartmann <tobias.hartmann at oracle.com>
Sent At:2020 May 11 (Mon.) 17:52
To:Sandler <zhuoren.wz at alibaba-inc.com>; hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Subject:Re: RFR:8243615 Continuous deoptimizations with Reason=unstable_if and Action=none

Hi Zhuoren,

thanks for the details. The same problem also affects other optimizations that only check
too_many_traps() and not too_many_recompiles(), right?

Best regards,
Tobias

On 08.05.20 11:26, Wang Zhuo(Zhuoren) wrote:
> Thanks for your comments. 
> 
>> But the Reason_unstable_if uncommon trap has Action_reinterpret (not Action_none) set?
> In GraphKit::uncommon_trap, if too_many_recompiles is true, Action_reinterpret will be changed
> to Action_none.
> 
>> Why don't we hit the too_many_traps limit?
> Likely that recompilations were caused by other reasons, not Reason_unstable_if. So we did not
> hit too_many_traps limit.
> Here comes an interesting thing, which byte code causes so many recompilations?
> Checkcast is very suspicious because I met a large number of deoptimizations with Reason_null_check
> in checkcast.
> Put it together, the whole process may be as follows,
> 1. Some byte code(maybe checkcast) caused a lot of deoptimizations and recompilations.
> 2. The number of deoptimizations and recompilations reached threshold, and in the last compilation
> for this method, Reason_unstable_if + Action_reinterpret was changed to Reason_unstable_if
> + Action_none.
> 3. We went into uncommon trap of Reason_unstable_if, but no more recompilation happened because
> of Action_none.
> Unfortunately I failed to write a standalone test to reproduce Reason_null_check in checkcast. So
> the test attached in bug link maybe a little different from the process I mentioned above.
> 
>> Also, there is a too_many_traps_or_recompiles method that should be used instead.
> Updated patch
> http://cr.openjdk.java.net/~wzhuo/8243615/webrev.02/
> 
> Regards,
> Zhuoren
> 
>     ------------------------------------------------------------------
>     From:Tobias Hartmann <tobias.hartmann at oracle.com>
>     Sent At:2020 May 7 (Thu.) 16:31
>     To:Sandler <zhuoren.wz at alibaba-inc.com>; hotspot-compiler-dev at openjdk.java.net
>     <hotspot-compiler-dev at openjdk.java.net>
>     Subject:Re: RFR:8243615 Continuous deoptimizations with Reason=unstable_if and Action=none
> 
>     Hi Zhuoren,
> 
>     On 26.04.20 14:31, Wang Zhuo(Zhuoren) wrote:
>     > I met continuous deoptimization w/ Reason_unstable_if and Action_none in an online application and significant performance drop was observed.
>     > It was found in JDK8 but I think it also existed in tip.
> 
>     But the Reason_unstable_if uncommon trap has Action_reinterpret (not Action_none) set?
> 
>     Why don't we hit the too_many_traps limit?
> 
>     Also, there is a too_many_traps_or_recompiles method that should be used instead.
> 
>     Thanks,
>     Tobias
>