The global object in browsers

Brendan Eich brendan at
Tue Feb 17 21:20:23 PST 2009

On Feb 17, 2009, at 8:17 PM, Mark Miller wrote:

> On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <brendan at>  
> wrote:
> On Feb 17, 2009, at 6:31 PM, Mark Miller wrote:
> Now that I think I understand "current" and how weak the legacy  
> constraints are, why not simply spec that your WindowProxy is the  
> object to treated as the ECMAScript global object? The consequence  
> would be that both f() and g() in your original example would return  
> 2.
> That either opens a huge security hole, or imposes costly runtime  
> checks on all lexical references to global variables.
> If Ian's Window object were provided as the ES global, then we'd  
> have the security problem you're concerned about. But, IIUC, with  
> the WindowProxy we don't.

That seems half-right. The ES global at the end of scope chains is the  
"inner" Window object. The perisistent-identity global that you get  
your hands on via the DOM, |this|, |self|, and |window| is the "outer"  
or WindowProxy object.

Which one did you mean by "the ES global" in the first sentence cited  

> As for performance, wouldn't a shallow binding implementation[1]  
> make switching which page is current be more expensive, but variable  
> access within a page, even after a switch, would have no added  
> expense?
> [1] The two primary methods of implementing dynamic scoping were  
> known as "shallow binding" and "deep binding". Although "current" is  
> not dynamic scope, some of the same issues and tradeoffs apply.

You are missing the requirement that the identity of the "outer"  
WindowProxy, which contains a series of documents loaded into it over  
time, remain the same, while the identities, plural, of the "inner"  
Window objects, each the global for its own document, also remain the  

> In a shallow bound implementation. the WindowProxy's properties are  
> direct properties -- not forwarded. On page navigation, these  
> properties are copied into the Window object corresponding to the  
> old page, and the properties on the Window object corresponding to  
> the new page are copied onto the WindowProxy.

And the scope chains for all the functions and activations in the old  
page are rewritten to refer to the Window object corresponding to the  
old page, not the WindowProxy? This does not scale at all.

And the reference monitor that checks access rights in the WindowProxy  
must run when the accesses come from only certain code. How does that  
work without disjoint global (end of scope chain) objects but  
persistent |this|? You can't know to skip the check and avoid a bad  
performance hit. The lexical references must suffer no penalty.

> Another analogy is with the register store in thread control blocks  
> in an OS implementation. One can describe the semantics of  
> computation in a given OS as directly updating the "current" per- 
> thread register set. But instead of paying the indirection on  
> register access, we'd rather pay the copying overhead on context  
> switch.

This doesn't work for security or performance.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list