so dropping retrieve*Something*FromVMCode which I believe is one reason methods with arguments/caller access cannot be optimized runtime properly is not a performance/"use strict" goal ? So now I am confused ... gonna dig there too ...
On Fri, Nov 16, 2012 at 2:36 PM, Oliver Hunt <oli...@apple.com> wrote: > > 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
