863518 - IonMonkey: Consider types added by loop body when unboxing OSR values

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

Attachment: patch

After bug 804676, OSR values are fallibly unboxed / type barriered according to the union of the types that the values could have when entering the loop with whatever values the OSR frame has during compilation.  This is fine when compiling on the main thread, as the values in the frame will be exactly those which are present when entering the compiled code.  However, with off thread compilation the variables could change in value between running IonBuilder and when the code is compiled and available to enter.  If a variable changes so that it is no longer in the above union, the compiled code bails out and gets stuck in baseline.

The attached patch fixes this situation by unboxing OSR values according to the union of the above two types *plus* the possible types accumulated for variables by compiling the loop body.  OSR unboxing is deferred until the end of compilation, when all the types for loop phis are known.

This doesn't seem to affect any benchmarks, but the nature of the failure --- likely to inflict large programs with massive and highly non-deterministic performance faults --- makes this worth fixing eagerly.

Comment 1

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/projects/ionmonkey/rev/9aff2a52d88b

Comment 2

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9aff2a52d88b