Bug 21214

Summary: speed up function calls by eliminating the need for a new ExecState each time
Product: WebKit Reporter: Darin Adler <darin>
Component: JavaScriptCoreAssignee: Darin Adler <darin>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: dglazkov, eric
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
Attachments:
Description Flags
work in progress
none
work in progress
none
patch that removes some unused ExecState cruft
none
patch that removes m_prev from ExecState
none
patch to remove some uses of dynamicGlobalObject none

Description Darin Adler 2008-09-29 09:05:18 PDT
Looks like I'm going to get rid of ExecState altogether and make the pointer we pass everywhere be a JSGlobalData pointer.
Comment 1 Darin Adler 2008-09-29 09:40:33 PDT
Created attachment 23910 [details]
work in progress
Comment 2 Darin Adler 2008-09-29 09:41:17 PDT
Created attachment 23911 [details]
work in progress
Comment 3 Darin Adler 2008-09-29 17:38:24 PDT
Created attachment 23924 [details]
patch that removes some unused ExecState cruft
Comment 4 Darin Adler 2008-09-29 18:14:56 PDT
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
Comment 5 Eric Seidel (no email) 2008-09-29 18:16:31 PDT
Interesting.  If ExecState dies, the "ExceptionHolder" abstraction we built to replace ExecState* for NodeFitler, NodeIterator, TreeWalker, etc.  will have to be re-thought.
Comment 6 Darin Adler 2008-09-30 16:24:15 PDT
Created attachment 23961 [details]
patch that removes m_prev from ExecState
Comment 7 Geoffrey Garen 2008-09-30 16:30:48 PDT
Comment on attachment 23961 [details]
patch that removes m_prev from ExecState

r=me

Please check SunSpider before landing.
Comment 8 Darin Adler 2008-09-30 16:47:17 PDT
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
Comment 9 Darin Adler 2008-10-01 14:04:01 PDT
Created attachment 23994 [details]
patch to remove some uses of dynamicGlobalObject
Comment 10 Eric Seidel (no email) 2008-10-01 15:12:39 PDT
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.
Comment 11 Darin Adler 2008-10-01 18:29:14 PDT
(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 12 Darin Adler 2008-10-01 18:30:56 PDT
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
Comment 13 Darin Adler 2008-10-02 16:38:51 PDT

*** This bug has been marked as a duplicate of 21295 ***