808448 - IonMonkey: Get rid of constraint-less invalidations (ion::ForceInvalidation)

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[Nicolas B. Pierron [:nbp]]

Contraint-less invalidations are a potential source of identical re-compilation.  Currently only 3 guardShape-s in IonBuilder are using Bailout_Invalidate.  Conceptually a guard should never invalidate because it provides a fallback to the interpreter for cases which are supposed to be infrequent.

An invalidation can only come from an input of the script a not from the script it-self. These 3 guards should monitor a state which cause the invalidation of the script instead of invalidating the script on their own.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

I think a better short-term solution for this is to have both bailout and recompilation limits on scripts (the longer term solution being the new baseline compiler). The problem isn't constraints per se, but lack of feedback. It's possible we don't need to invalidate at all on a shape guard failure, but then we would need the bailout limit.

Comment 2

[Nicolas B. Pierron [:nbp]]

(In reply to David Anderson [:dvander] from comment #1)
> I think a better short-term solution for this is to have both bailout and
> recompilation limits on scripts (the longer term solution being the new
> baseline compiler).

The short-term goal of this bug, is just to replace ForceInvalidation by a function which register a state in TI, and assert that the script is going to be invalidated instead of invalidating it.

The long term goal would be to make Invalidation impossible without providing feedback/delta.  Which by the way should help gather information for devtools.

I agree, that in the mean time we need a mechanism for warning/preventing about such behaviour, but I think we need to open another bug for that, if there isn't one already.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

What actual bug is this intended to fix?

Comment 4

[Nicolas B. Pierron [:nbp]]

(In reply to David Anderson [:dvander] from comment #3)
> What actual bug is this intended to fix?

I opened this bug as a clean-up.  I have no idea if this might be related to a compilation loop, but this is the kind of thing we should avoid.