548844 - keep the current global object on the contiguous stack

Status: RESOLVED DUPLICATE of bug 561923

(Core :: JavaScript Engine, defect)

Description

[Luke Wagner [:luke]]

JSC stores the current global object (the root of the current scope chain) at the "bottom" of their contiguous stack, having it grow downward as new global properties are added.  When the current global object is changed, the old global object is copied out to object dslots and the new global is copied in.  This scheme provides faster access to globals by removing indirection.  Also, when we move to the dual stack layout (measured in bug 539123), global object properties will stay unboxed for as long as they are kept on the stack, as opposed to being unboxed/reboxed on every getglobal/setglobal op.

One thing that needs to be measured first, though, is how often we change global objects in webapps and benchmarks since this may differ between WebKit and Mozilla.

Comment 1

[Luke Wagner [:luke]]

> This scheme provides faster access to globals by removing indirection.

Not just a little either; in JM this should be the difference between, for every global read,

  load, branch, load, load, shift, branch, load, sub, load

and

  load, load

or even just "load" on x64 where we could pin cx->stack().base to a register.  Mighty attractive...

Comment 2

[Luke Wagner [:luke]]

(Recording IRL discussion with Brendan)
If we really want the optimal 'load from constant offset' global access in method-jited code, we are saying that JITed methods need to bake in slot offsets, which implicitly ties JITed methods to globals.  This implies, like the tracing-jit, keying JITed code on a (script,global) pair (within a JSThreadData), instead of just the script.  (Also changing global property delete logic to never recycle slots of deleted properties.)  This has the potential to compile more code, but it is rare to have a single script executed with different globals (for one, it requires JSAPI use of JS_ExecuteScript (and kin) or JS_CloneFunctionObject.)  A notable use of this is the "brutal sharing" done in Firefox with cloned XUL windows.  However, we could weaken the "same global" requirement to "same shape" or even something weaker which allows baked-in offsets to be valid across globals.  Measurement is required to see how much potential duplication we are talking about with the various schemes.

Comment 3

[Luke Wagner [:luke]]

A word on shared globals:
Currently, the tracing-jit avoids race conditions by testing the global's ownercx.  With the multi-threading Plan Of Record, this will go away and, if needed, synchronization will be handled by an object's object ops, with native object ops doing no locking.  Since we currently assert a global object is native, this will (initially) force the global object to be single-threaded.  If we loosen this, JM will need to check (perhaps falling back to the interpreter on fail) that the global object is native.

and on aliased globals:
We can redirect, in the manner of Call and Arguments objects, global property access to the values stored on the stack, so that, at any time, there is a single point of truth.  If (to avoid swapping globals on/off the stack) we go with keeping multiple simultaneous unboxed globals, it seems like we could simply use the unboxed storage exclusively in lieu of jsval dslots.

Comment 4

[Andreas Gal :gal]

Changing the property delete logic to not recycle slots is trivial. I have done this before for an experiment.