619693 - TypeInference: API for type write barriers

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

Within C++ code, type inference needs barriers for property definitions/sets on objects for which (a) the inference purports to know the property types and (b) the side effect is not modeled by the inference.

(a) known objects include native objects and dense arrays which do not have unknownProperties set in their type.
(b) modeled side effects include all direct side effects in a script except those at bytecodes with monitorNeeded set (these are property sets where the LHS is unknown), and those described by the type handler for a native function.

This effectively includes all native/array side effects except those in Interpret and perf-critical native functions.  For now, the latter can be restricted to JSON, String, RegExp, and Array natives when applied to dense arrays, expand this as needed.

These barriers are currently implemented as calls to JSContext::addTypeProperty which occur alongside the native set itself.  This is an error prone design (see bug 619333); we should instead have an API that does both, and grep the code to make sure that every place we set a property and both (a) and (b) *could* hold, we use this API.

Comment 1

[Brian Hackett [Laid off!]]

First step, add assertions about the correctness of type information within properties.  Basically, whenever we do any getProperty (whether native or not), by the time that getProperty finishes the type information on the object should reflect the result value.  This additionally asserts that when a native setProperty or defineProperty occurs that the type information already reflects the value being written, to catch bugs earlier (generally, types should be updated before doing a setProperty, in case the type operation fails due to OOM).

http://hg.mozilla.org/projects/jaegermonkey/rev/ada129dc08ad

Comment 2

[Brian Hackett [Laid off!]]

Patch below removes JS_DefinePropertyWithType and makes JS_DefineProperty add type information for each property added in this way.  This also turns inference on by default for tinderbox testing.

http://hg.mozilla.org/projects/jaegermonkey/rev/37ab40cd90ad

Comment 3

[Brian Hackett [Laid off!]]

I think things here are in pretty good shape, with little modification to the JS API.  obj->defineProperty and obj->setProperty do not update the type sets for properties, but API functions and other wrappers that define or set properties generally do update the sets --- there is no need to make two calls.  I haven't seen any places where DOM or other client code writes to objects bypassing the API, but should still grep.  This could either be that they don't have such behavior, or that the objects they're updating all have unknown properties anyways.  In any case, the assertions added in comment 1 are in a good position to catch current or future type violations.

Comment 4

[Brian Hackett [Laid off!]]

Reopening, while the JSAPI is fine I'd like to call addTypeProperty automatically during the primitive JS-internal obj->setProperty/addProperty/etc. functions, to make maintaining type information from the VM less error prone (see bug 647464).

Comment 5

[Brian Hackett [Laid off!]]

Remove most calls to addTypeProperty, get functions in and under obj->setProperty, obj->defineProperty and obj->getProperty to update types in the appropriate places.  It's harder to sneak past the barriers now, but this can still be done with direct slot writes.

http://hg.mozilla.org/projects/jaegermonkey/rev/f18e992f6ec8