Bug 21295

Summary:

Replace ExecState with a call frame Register pointer

Product:

WebKit

Reporter:

Cameron Zwarich (cpst) <zwarich>

Component:

JavaScriptCore

Assignee:

Darin Adler <darin>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

darin, ggaren

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Bug Depends on:

Bug Blocks:

20812

Attachments:

Description	Flags
some work in progress on getting fields out of ExecState	none
patch	none
patch	zwarich: review+

Cameron Zwarich (cpst)

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

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 attachment proposed patch, testcase, etc.

Darin Adler

Comment 1 2008-10-02 16:38:51 PDT

*** Bug 21214 has been marked as a duplicate of this bug. ***

Darin Adler

Comment 2 2008-10-02 17:07:49 PDT

Created attachment 24036 [details] some work in progress on getting fields out of ExecState

Darin Adler

Comment 3 2008-10-03 12:03:56 PDT

Created attachment 24059 [details] patch

Geoffrey Garen

Comment 4 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.

Darin Adler

Comment 5 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.

Darin Adler

Comment 6 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().

Geoffrey Garen

Comment 7 2008-10-03 14:04:49 PDT

okeedokee!

Darin Adler

Comment 8 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

Darin Adler

Comment 9 2008-10-04 13:11:53 PDT

Created attachment 24090 [details] patch

Cameron Zwarich (cpst)

Comment 10 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.

Darin Adler

Comment 11 2008-10-04 14:14:23 PDT

http://trac.webkit.org/changeset/37297

Note You need to log in before you can comment on or make changes to this bug.