Looks like I'm going to get rid of ExecState altogether and make the pointer we pass everywhere be a JSGlobalData pointer.
Created attachment 23910 [details] work in progress
Created attachment 23911 [details] work in progress
Created attachment 23924 [details] patch that removes some unused ExecState cruft
Comment on attachment 23924 [details] patch that removes some unused ExecState cruft Clearing review flag since this was landed. http://trac.webkit.org/changeset/37088
Interesting. If ExecState dies, the "ExceptionHolder" abstraction we built to replace ExecState* for NodeFitler, NodeIterator, TreeWalker, etc. will have to be re-thought.
Created attachment 23961 [details] patch that removes m_prev from ExecState
Comment on attachment 23961 [details] patch that removes m_prev from ExecState r=me Please check SunSpider before landing.
Comment on attachment 23961 [details] patch that removes m_prev from ExecState Clearing review flag since this is landed. http://trac.webkit.org/changeset/37125
Created attachment 23994 [details] patch to remove some uses of dynamicGlobalObject
Comment on attachment 23994 [details] patch to remove some uses of dynamicGlobalObject None of these dynamic -> lexical change behavior? It's not possible to override the object prototype I assume? (thus it's functionally equivalent to ask on either global object?) The shell ones I would believe, since no one really cares about the shell, the Object.prototype I have less context for to make an informed decision. Otherwise looks fine.
(In reply to comment #10) > None of these dynamic -> lexical change behavior? It's not possible to > override the object prototype I assume? (thus it's functionally equivalent to > ask on either global object?) The shell ones I would believe, since no one > really cares about the shell, the Object.prototype I have less context for to > make an informed decision. As Geoff explained to me, the general principle here is that the dynamic global object (bad name we should improve) is never the correct one for security purposes because it corresponds to the page where the current code started from, not the page that corresponds to the code being run. There is a change in behavior, but not for the web browser. Only in obscure cases of use of the JavaScriptCore API. I'll think about whether I can make a test case to demonstrate the improvement.
Comment on attachment 23994 [details] patch to remove some uses of dynamicGlobalObject Clearing review flag since this was landed. http://trac.webkit.org/changeset/37175
*** This bug has been marked as a duplicate of 21295 ***