"no strict"; directive

Oliver Hunt oliver at apple.com
Fri Nov 16 14:36:57 PST 2012

On Nov 16, 2012, at 2:11 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

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

Not understanding how features need to be/are implemented (or an unwillingness to investigate) isn't a good basis for making statements like this.

What you seem to be (willfully) ignoring is that someFunction.caller requires a stack walk.  That is what it is defined as doing.

|arguments| is a magic _local_ variable - there is no stack walk involved, only the local call frame matters, there is no stack reconstruction necessary (in the sane use cases any way - insane use cases trigger dramatic costs, and someFunction.arguments has all the problems on someFunction.caller, with a few additional costs thrown in for good measure).


> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121116/48a7d3cc/attachment.html>

More information about the es-discuss mailing list