"no strict"; directive

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Nov 16 14:11:04 PST 2012

but I don't see caller being any better/worse than arguments and I believe
arguments will stick around "forever" in any case ... so will caller,
unless there's not some specific personal reason but the code just looks
basically the same: find the rabbit and "ta-daaaaa"

Yes, it would be silly to create today something based on an assumption
such "future browsers optimizations will come after ES6" but on the
practical level we all know it's going to be like that, right? Or even ES7
... thanks for your answer.

On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden <jwalden+es at mit.edu> wrote:

> On 11/16/2012 01:42 PM, Andrea Giammarchi wrote:
> > @Oliver, if you need to retrieve the caller in order to know if it's
> strict or not, then everything I've read in this thread becomes kinda
> pointless :-(
> Not quite.  You could imagine a system where you simply have to know if
> your caller is strict or not.  If it is, then you don't need to track any
> of that info.  If it isn't, then you'd need some system to compute the
> caller.  But it's certainly not the case that you always have to keep the
> caller around regardless.
> >
> https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184
> >
> > It looks like there's no gain at all using strict and the goal here is
> "simply" to get rid of these calls exec->interpreter
> > ()->retrieve*something*FromVMCode(exec, thisObj);
> Just to note, knowing that it's impossible to access the caller also
> benefits inlining -- you don't have to be able to recompute the caller
> function (or all the inlined function's stack modifications) at any moment
> when you're in function code that's been inlined in a caller.  I would
> provide you a link to a blog post I wrote a year or so ago with more
> details on this, but it's currently down.  :-(  Maybe I should spend the
> time to bring it back up now so I can pass that link along.
> > am I wrong? Can I ask when and if it's planned to get rid of this
> isStrictMode() method? This, as info, would be definitively valuable ( FF
> and Chrome guys welcome to answer to this as well, thanks )
> I wouldn't speculate as to when any engine will take advantage of this --
> SpiderMonkey that I work on, or any of the others.  It's still somewhat
> early in the JS optimization race, so it's likely there's more low-hanging
> fruit to be picked in all the engines, that benefits all code and not just
> strict mode code, before this would happen.  As regards SpiderMonkey
> particularly, I think we have enough things on our plates now that taking
> advantage of this particular optimization opportunity won't happen in the
> next year or so.
> Taking advantage of this also has some interesting interactions with other
> functionality like debuggers, Error.stack, error messages, and so on.  The
> simple thing, that's been done forever, is to just always track it.  But
> there's no reason not to specialize, and optimize harder, in the cases
> where these complications can be worked around or set aside.
> In the long run, however, something like this will happen.  It would be
> short-sighted to take on the semantic nightmare mid-stream strict mode
> opt-out would present, simply because engines aren't immediately taking
> advantage of all the optimization opportunities strict mode presents.
> Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121116/5f0f630a/attachment.html>

More information about the es-discuss mailing list