Bug 21295 - Replace ExecState with a call frame Register pointer
Summary: Replace ExecState with a call frame Register pointer
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Adler
URL:
Keywords:
: 21214 (view as bug list)
Depends on:
Blocks: 20812
  Show dependency tree / graph
 
Reported: 2008-10-01 23:11 PDT by Cameron Zwarich (cpst)
Modified: 2008-10-04 14:14 PDT (History)
2 users (show)

See Also:

Attachments
some work in progress on getting fields out of ExecState (37.60 KB, patch)
2008-10-02 17:07 PDT, Darin Adler 		no flags Details | Formatted Diff | Diff
patch (82.38 KB, patch)
2008-10-03 12:03 PDT, Darin Adler 		no flags Details | Formatted Diff | Diff
patch (83.54 KB, patch)
2008-10-04 13:11 PDT, Darin Adler 		zwarich: review+
Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Cameron Zwarich (cpst) 2008-10-01 23:11:12 PDT 
Darin has been working on replacing ExecStates with a call frame Register pointer. This should be a small increase in function call performance.
Comment 1 Darin Adler 2008-10-02 16:38:51 PDT 
*** Bug 21214 has been marked as a duplicate of this bug. ***
Comment 2 Darin Adler 2008-10-02 17:07:49 PDT 
Created attachment 24036 [details]
some work in progress on getting fields out of ExecState
Comment 3 Darin Adler 2008-10-03 12:03:56 PDT 
Created attachment 24059 [details]
patch
Comment 4 Geoffrey Garen 2008-10-03 13:11:22 PDT 
Comment on attachment 24059 [details]
patch

+        ScopeChainNode(ScopeChainNode* next, JSObject* object, JSGlobalData* globalData, JSObject* globalThis)
+            : next(next)
+            , object(object)
+            , globalData(globalData)
+            , globalThis(globalThis)

I don't think you ended up using this, did you?

r=me -- should probably remove the ScopeChainNode change.
Comment 5 Darin Adler 2008-10-03 13:54:22 PDT 
(In reply to comment #4)
> (From update of attachment 24059 [details] [edit])
> +        ScopeChainNode(ScopeChainNode* next, JSObject* object, JSGlobalData*
> globalData, JSObject* globalThis)
> +            : next(next)
> +            , object(object)
> +            , globalData(globalData)
> +            , globalThis(globalThis)
> 
> I don't think you ended up using this, did you?

Yes, I did. That's still the way we get JSGlobalData faster in the more typical cases. It's possible we could roll that optimization back out because the really hot cases get it from the CTI. But all my performance testing has been with both mechanisms in place.
Comment 6 Darin Adler 2008-10-03 13:55:14 PDT 
(In reply to comment #5)
> Yes, I did. That's still the way we get JSGlobalData faster in the more typical
> cases.

More typical case means anyone who calls exec->globalData().
Comment 7 Geoffrey Garen 2008-10-03 14:04:49 PDT 
okeedokee!
Comment 8 Darin Adler 2008-10-03 14:43:49 PDT 
Comment on attachment 24059 [details]
patch

Clearing flag since I landed this.

http://trac.webkit.org/changeset/37257
Comment 9 Darin Adler 2008-10-04 13:11:53 PDT 
Created attachment 24090 [details]
patch
Comment 10 Cameron Zwarich (cpst) 2008-10-04 14:06:58 PDT 
Comment on attachment 24090 [details]
patch

r=me if you do the

#define exec CallFrame::create(r)

workaround for the local variable 'exec' in Machine::privateExecute() that we discussed, and then remove the use of 'exec' afterwards in a followup patch.
Comment 11 Darin Adler 2008-10-04 14:14:23 PDT 
http://trac.webkit.org/changeset/37297