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

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bhackett, Unassigned)

Tracking

Other Branch
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
Created attachment 739359 [details] [diff] [review]
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.
Attachment #739359 - Flags: review?(dvander)
Attachment #739359 - Flags: review?(dvander) → review+
(Reporter)

Comment 1

5 years ago
https://hg.mozilla.org/projects/ionmonkey/rev/9aff2a52d88b
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/mozilla-central/rev/9aff2a52d88b
Depends on: 876098
You need to log in before you can comment on or make changes to this bug.