891172 - IonMonkey: Investigate inserting unconditional bailouts on constraint failures.

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Nicolas B. Pierron [:nbp]]

The constraint system is good because it prevents the addition of guards and allow hot-path to be executed without running any checks.  On the other hand, as soon as a constraint is invalidated, the code execution must stop and bailout after any return into the remaining Ion instances on the stack.

The idea suggested here, is instead of having transparent constraints which are invalidating all the code, we could have no-op guards which are tied to a constraint.  The idea has 2 direct implications:
 - The constraint would be part of the code allocation (because it would refers to code offsets)
 - The constraint invalidation will cause the guard to be patched to bail constantly.

The advantage is that if the invalidation cause a slow path to be patched, we would still be able to run inside Ion while we could be recompiling in parallel the next generation of the IonScript based on the newly accumulated baseline-data.

If the invalidation cause a hot-path to be patched, we could deactivate the code after detecting frequent bailouts (Bug 825268), and run in the baseline code, only if the Ion code is no longer more efficient.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

This sort of has been done; what is described here sounds very similar to how we transpile CacheIR stubs in warp. Marking as "worksforme" simply because I think this islargely done (constraints have also been removed)