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

[Wang Zhuo(Zhuoren)]

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