Closed Bug 653639 Opened 9 years ago Closed 9 years ago
TI: understand types of window objects
Global objects in the browser are generally windows, the types of whose properties are currently unknown to inference. To understand the types of global variables in browser scripts (pretty critical for perf!), we need to understand the types of the windows.
Keep enough type information around in XPConnect to track the types of window object properties (we still don't know anything about DOM nodes and DOM-related functions ('alert' etc.) and treat them as generic objects and functions). Main things this does: - Make a unique type for the initial prototypes of window objects, which were previously unknown generic objects. - Allow JSAPI clients to splice new prototypes onto objects with singleton types. The proto on the type object is updated in place without needing to change the type of the holding JSObject. http://hg.mozilla.org/projects/jaegermonkey/rev/e0cb191ba873
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Oversight where we didn't mark type objects as unknown when splicing in a prototype with unknown properties. This hit on the GlobalScopePolluter, which this patch fixes up. http://hg.mozilla.org/projects/jaegermonkey/rev/81926bb75b41
Add a read barrier for types when getting properties from shapes with non-standard getters. Previously we just asserted and needed these getters to add the types manually. This is needed to handle various quickstub getters getting properties from window objects, would rather put the type management stuff behind the API rather than mess around with lots of client code (not just quickstubs) to add types in the right places. http://hg.mozilla.org/projects/jaegermonkey/rev/9723b731e828
You need to log in before you can comment on or make changes to this bug.