The global object in browsers

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Fri Feb 20 03:24:27 PST 2009


Maciej Stachowiak wrote:
> On Feb 19, 2009, at 1:39 AM, David-Sarah Hopwood wrote:
>> Ian Hickson wrote:
>>> On Tue, 17 Feb 2009, Mark Miller wrote:
>>>> On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson <ian at hixie.ch> wrote:
>>>>> Indeed, I noted this earlier. The behavior HTML5 codifies is the
>>>>> behavior that the majority of browser vendors have asked me to codify.
>>>> Majority, huh? Which vendors? How does the behavior they ask for
>>>> correlate with what their browsers do?
>>>
>>> Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE
>>> does, namely throw an exception when running code whose global object doesn't
>>> match the current Window object, but Opera, Apple, and Mozilla rejected
>>> this on the grounds that it could not be implemented in a
>>> high-performance manner.
>>
>> That is clearly false. It would be a single pointer comparison when
>> entering a new context.
>>
>> I make no comment here on whether this behaviour would be a good idea on
>> other criteria, just that rejecting it on performance grounds is absurd.
> 
> In modern JITing implementations, adding (at least) two memory reads and
> a conditional branch to every function call would be a significant
> performance hit.

It is not every function call; only function calls that are not known
to be same-context (in a particular copy of the generated code). The
majority (by call frequency) of function calls can be inferred to be
same-context by analyses that a high-performance implementation should
be doing already. Furthermore, the context check can be hoisted to the
first point in a function body where the target function is known (so
calls to the same function in a loop will require only one check).

There are most sophisticated optimizations that could be done, but
they're probably not needed.

> In JavaScriptCore for instance, the hot path at the
> machine code level is optimized down to essentially just one memory
> read, one conditional branch, and a jump to the callee's code (also some
> memory writes but those don't stall the pipeline so they don't matter as
> much). The next hottest path has three branches and a few extra memory
> reads. Adding an extra branch (and associated memory reads) to that
> would be a big hit. We know because we have measured the benefit of
> reducing the number of branches. It makes a huge difference in
> call-heavy code.
> 
> In general, I would advise against making performance claims in absolute
> terms (like "clearly false") without testing or studying the relevant
> implementation internals.

I see no point in equivocating on points that I am quite sure about,
having studied similar issues in implementations of other languages.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list