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

[Nils Eliasson]

I suggest adding a JFR event for catching these rare situations.

Regards,
Nils

On 2020-05-11 22:15, John Rose wrote:
> On May 11, 2020, at 5:58 AM, Wang Zhuo(Zhuoren) <zhuoren.wz at alibaba-inc.com> wrote:
>> 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.
> Here’s some background:
>
> The too_many_traps logic is like those barrels full of sand or water
> at the edges of freeway intersections, or a backstop on a baseball field.
> It’s better to have a backstop than to have none at all, but something
> is wrong if you are hitting the backstop.
>
> In short, the too_many_traps logic is present to prevent trap storms
> from lasting forever.  But even short trap storms are a problem, if
> they happen often enough.  Also, the too_many_traps logic has
> in the past failed to terminate trap storms.
>
> I think the bug here is probably whatever specific factor is causing
> small trap storms, which in turn are triggering too_many_traps.
> Maybe there’s a bytecode that is trapping too often, and that bytecode
> individually is not throttling its own traps, and so the generic
> backstop logic is being called into play.
>
> (Less likely, the generic throttling logic needs some fix.  But usually
> the right fix is at the root cause, with a single optimization or bytecode
> that is going wrong too often.)
>
> Sometimes it’s one bytecode running one corner case optimization
> that is trapping too many times, as if the JIT’s optimizer were saying
> to itself “last time this optimization failed, but this time for sure!”,
> or as if the JIT’s optimizer has no feedback path at all to see that the
> optimization has failed in the past.  Sometimes it is a whole class of
> bytecodes, such as “all check-casts arising from generic erasure.”
>
> HTH
>
> — John