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

[John Rose]

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