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"<div>
<br></div><div>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.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 2:02 PM, Jeff Walden <span dir="ltr"><<a href="mailto:jwalden+es@mit.edu" target="_blank">jwalden+es@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/16/2012 01:42 PM, Andrea Giammarchi wrote:<br>
> @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 :-(<br>
<br>
</div>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.<br>

<div class="im"><br>
> <a href="https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184" target="_blank">https://trac.webkit.org/browser/trunk/Source/JavaScriptCore/runtime/JSFunction.cpp#L184</a><br>
><br>
> 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<br>
> ()->retrieve*something*FromVMCode(exec, thisObj);<br>
<br>
</div>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.<br>

<div class="im"><br>
> 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 )<br>
<br>
</div>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.<br>

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

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

<span class="HOEnZb"><font color="#888888"><br>
Jeff<br>
</font></span></blockquote></div><br></div>