Last Comment Bug 637674 - TypeInference: handle OOM
: TypeInference: handle OOM
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: Brian Hackett (:bhackett)
: Jason Orendorff [:jorendorff]
Depends on: 613221 817475
Blocks: TypeInference
  Show dependency treegraph
Reported: 2011-03-01 08:32 PST by Brian Hackett (:bhackett)
Modified: 2012-12-02 19:41 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (385.74 KB, patch)
2011-03-03 14:14 PST, Brian Hackett (:bhackett)
no flags Details | Diff | Splinter Review

Description User image Brian Hackett (:bhackett) 2011-03-01 08:32:45 PST
Most inference code doesn't handle or propagate OOM conditions when constructing type information or doing analysis.  Conceptually, once bug 613221 is done it is OK to abort analysis of a script (which will not then be compiled), but any operation updating the core type information (making a type object, adding to the type set of a variable/property) must cause the corresponding JS operation to fail on OOM.  The goal here is to preserve the invariant that the core type information overapproximates the feasible types in the compartment.
Comment 1 User image Brian Hackett (:bhackett) 2011-03-03 14:14:35 PST
Created attachment 516704 [details] [diff] [review]

This fixes OOM handling for inference code and code which uses inference.  It also removes --enable-type-inference and JS_TYPE_INFERENCE, instead making inference a runtime switch ('-n' in the shell, eventually javascript.options.typeinference in the browser).  Inference is enabled per-compartment, at the time when the compartment is created.
Comment 2 User image Brian Hackett (:bhackett) 2011-05-18 12:39:54 PDT
Comment 0 is too optimistic --- for most allocations during inference, if the allocation fails and we unwind the stack we still leave the analysis in an inconsistent state (e.g. type constraints not fully propagated) which we can't correctly recover from the next time someone tries to update the type information.  So we want to just disable inference on compartments after an OOM.  Before the interpoline this was problematic, as disabling inference required recompilation and recompilation could fail (especially if there was just an OOM).  Now, however, we can discard jitcode infallibly by redirecting those frames to the interpreter, which makes handling OOM during analysis much simpler.

Note You need to log in before you can comment on or make changes to this bug.