"no strict"; directive

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Nov 16 14:35:49 PST 2012


I didn't misunderstand the cost ... I have said it's actually indeed
pointless to say it costs something since the simple check, that isStrict()
is performed at the end, when the rest of the logic has been moved already.
Thanks for all other infos


On Fri, Nov 16, 2012 at 2:31 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Nov 16, 2012, at 1:42 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> 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 :-(
>
> 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);
>
> 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 )
>
>
> Okay, so there are two issues:
> 1. calling someFunction.caller when someFunction is itself strict
> 2. calling someFunction.caller when someFunction.caller is strict
>
> 1. is trivial: before we do any work we check whether someFunction is
> strict and throw if appropriate
> 2. is weird -- this code post-dates my original strict mode
> implementation, presumably it exists due to someone adding a test for it in
> test262.
>
> I'm not sure of what the value of the restriction in (2) is meant to be,
> I'm sure MarkM or Waldemar could say for sure, but I assume it's part of
> the early failure desires of strict mode.  My personal bias in favour of
> code that continues to run all the time means I would rather return null
> (after all null is already a possible result).
>
> Okay, that aside you seem to be misunderstanding what the cost model is
> here.  Calling isStrictMode() is obviously trivial (there's a bool flag
> that says whether a function is strict).
>
> But that's not the cost we're concerned about.  There's a lot of
> complexity in the engine that is required in order to support .caller, and
> a lot of runtime costs involved in storing the things that are necessary
> for recovering it.
>
> This is the algorithm that .caller has to use is basically:
> GetCaller(function)
>   stackFrame = topStackFrame
>   while (stackFrame) {
>      callerFrame = stackFrame.callerFrame
>      if (stackFrame.callee == function) {
>          if (!callerFrame || !isFunction(callerFrame.callee))
>              return null
>          return callerFrame.callee
>      }
>      stackFrame = callerFrame
>   }
>   return null
>
> So this is expensive on its own and prevents tailcall optimisations
> (because a tailcall directly breaks .caller).
>
> The other problems are that trying to retrieve callerFrame is not free, it
> requires undoing inlining and a variety of other optimisations, recreating
> a correct call stack (not cheap) and potentially disables those
> optimisations again in the future.
>
> Again the cost here is not checking for strict mode it's:
> * The cost of walking the stack
> * The cost of storing information required to determine what the actual
> function object is so we can give you the caller function, rather than the
> internal type that contains the function metadata (even if you never use
> .caller)
> * The cost of deoptimising code when .caller is actually used
> * The opportunity cost of completely preventing certain classes of
> optimisation (again: even if you never use .caller)
>
> Strict mode disables .caller because it is a misfeature, however we're
> still required to support it for non-strict code hence the very large
> amounts of code needed for it continues to exist.
>
> --Oliver
>
>
>
>
> On Fri, Nov 16, 2012 at 1:01 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
> P.S. Alex, just to be as clear as possible, one answer I did not like that
> much was that eval('"no strict"') nonsense ... that was not an answer
> 'cause problems are the same with eval('"use strict"') and we, JS
> developers, are not always noobs or dumb.
>
> It happens, from time to time, that we know what we are talking about and
> why we need this or that thing.
>
> It's nice when here we keep it easy and quite ... it's also rare, imho.
>
>
> On Fri, Nov 16, 2012 at 12:57 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
> neither does `with` so the day use strict will be the default 90% of tests
> frameworks will nicely break as well.
>
> There are tons of libraries still based on ES3 and those "evil" things.
>
> I am the first one to use always latest, and use strict too, but there are
> cases where those "evil" things cannot be replaced and maybe are useful and
> for good.
>
> As long as there is a "no strict" behavior supported by engines I am good
> in any case but it's a pity we cannot have that solution today .. is the
> only one that makes sense out there, the only that does not suffer all
> other problems plus does not impact performance of each methods when super
> call is something actually not that common or not always needed when
> inheritance is in place.
>
> I've solved this a while ago with a better approach, even better than the
> currently de-sugared TypeScript, but developers are lazy and this new
> solution would have made them happy in their laziness.
>
> Thank everyone in any case for all inputs and thoughts and facts, I guess
> I am done here.
>
> br
>
>
>
> On Fri, Nov 16, 2012 at 12:38 PM, Alex Russell <alex at dojotoolkit.org
> > wrote:
> I'm a huge fan of that too -- you know I don't like compilers as the
> answer -- but that approach always comes with limits; and that's OK. What
> we add to the spec lives forever; not just through the transition. We owe
> it to ourselves and our users to introduce the least crazy we can while
> still solving the most pressing problems; and to do it with an eye toward
> living in the future were specing. Caller doesn't pass this smell test.
>
> On Nov 16, 2012 4:55 PM, "Andrea Giammarchi" <andrea.giammarchi at gmail.com>
> wrote:
> I am still a big fun of what made JS easy to use, develop, learn since
> born ... the ability to include a script in a HTML page and run it without
> being forced of using different tools in the middle before results or even
> requiring a web server at all.
>
> I remember once I've read that scripting was cool 'cause no time wasted
> compiling ... those days are gone in modern JS development.
>
> br
>
>
> On Fri, Nov 16, 2012 at 6:01 AM, Alex Russell <alex at dojotoolkit.org
> > wrote:
> On Nov 16, 2012, at 1:02 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
> > "use strict" is removed from code by default ... this is where it goes
> once
> > minified: nowhere.
> >
> > I would rather force a minifier explicitly to remove it rather than force
> > it to keep it for ES5 ... also ES5 is not use strict so I don't get this
> > Closure Compiler choice.
> >
> > I don't see minified code with "use strict" that often
>
> All this suggests is that we need to improve the state of play in tools.
> Sounds doable.
>
> That said, you've gotten good answers that you don't like. It happens, and
> it's better than not getting an answer or getting a bad one.
>
> The polyfill you're working on can be accomplished other ways (
> http://code.google.com/p/traceur-compiler/). There's always a tax for
> emulating the new thing with the old, and this case that's caller. More to
> the point, it's a polyfill; once ES6 lands in engines, class syntax will
> give you super() for free, complete with whatever optimizations make sense.
>
> If you have performance issues, I recommend what everyone else here has:
> write benchmarks and file bugs. Beyond that, I think this horse is both
> dead and beaten.
>
> > On Thu, Nov 15, 2012 at 4:40 PM, Brendan Eich <brendan at mozilla.com>
> wrote:
> >
> >> Andrea Giammarchi wrote:
> >>
> >>> Said that, I would rather force removal of "use strict" 'cause if there
> >>> is explicit desire from the developer. Isn't it?
> >>>
> >>
> >> What do you mean? "use strict" is not going away. It is used by some
> >> developers. I had a show of hands at JSConf.au, definitely a minority
> but
> >> significant.
> >>
> >> You are barking up the wrong tree. And Angus's abuses of 'with' are
> >> unjustified. Yes, "be water". Yes, masters may break rules students must
> >> follow. None of that philosophizing justifies 'with' abusage or
> >> repealing/undoing "use strict".
> >>
> >> /be
> >>
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
> --
> Alex Russell
> slightlyoff at google.com
> slightlyoff at chromium.org
> alex at dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> _______________________________________________
> 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/e9a88dee/attachment-0001.html>


More information about the es-discuss mailing list