Last Comment Bug 653639 - TI: understand types of window objects
: TI: understand types of window objects
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
-- normal (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 619433
  Show dependency treegraph
Reported: 2011-04-28 19:38 PDT by Brian Hackett (:bhackett)
Modified: 2011-04-30 19:48 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Brian Hackett (:bhackett) 2011-04-28 19:38:31 PDT
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.
Comment 1 User image Brian Hackett (:bhackett) 2011-04-30 18:10:47 PDT
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.
Comment 2 User image Brian Hackett (:bhackett) 2011-04-30 18:21:53 PDT
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.
Comment 3 User image Brian Hackett (:bhackett) 2011-04-30 19:48:27 PDT
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.

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