On Nov 16, 2012, at 2:11 PM, Andrea Giammarchi <andrea.giammar...@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). --Oliver > > > On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden <jwalden...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
