Last Comment Bug 653639 - TI: understand types of window objects
: TI: understand types of window objects
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: general
:
: Jason Orendorff [:jorendorff]
Mentors:
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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description 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 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.

http://hg.mozilla.org/projects/jaegermonkey/rev/e0cb191ba873
Comment 2 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.

http://hg.mozilla.org/projects/jaegermonkey/rev/81926bb75b41
Comment 3 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.

http://hg.mozilla.org/projects/jaegermonkey/rev/9723b731e828

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