JSStackFrame Evisceration: Difference between revisions
Jump to navigation
Jump to search
| Line 54: | Line 54: | ||
| [https://bugzilla.mozilla.org/show_bug.cgi?id=535912 blockChain] | | [https://bugzilla.mozilla.org/show_bug.cgi?id=535912 blockChain] | ||
| 1 | | 1 | ||
| | | | ||
| A bit tricky | | A bit tricky | ||
|- | |- | ||
Revision as of 06:00, 5 August 2010
This would leave sizeof(JSStackFrame) == 6 words.
Members to remove
Sorted in estimated order of benefit / difficulty:
| Task | Size (wks) | Assignee | Note |
| argc/argv | 1.5 | lw | Requires CallSegment (CallStack) changes, educate decompiler |
| thisv | .5 | lw | Depends on argv/argc |
| fun, script | .5 | lw | Depends on thisv |
| ncode | 3 | dvander | Merge it with savedPC in method-jit. Requires building map HW PC --> bytecode (which we sortof already heave |
| XdisplaySave | 1 | cdleary | Remove display optimization for great justice! |
| hookData | 1 | Once we are inlining call paths, we can know statically, based on the compartment-wide 'debug mode' flag, whether we can just ignore cx->debugHooks->callHook and leave hookData uninitialized. To actually remove the JSStackFrame member (without having the size depend on whether we are in debug mode or not), we can maintain a debugHook stack on the side. | |
| annotation | 3 | sayrer | Trivial if we can remove callers in nsScriptSecurityManager. Alas, that is not trivial, so this is going to take a while. |
| callerVersion | .5 | cdleary | Mostly the challenge is just understanding the actual use case. |
| blockChain | 1 | A bit tricky | |
| rval | 1 | Tricky | |
| imacpc | 1 | cdleary | Leave uninitialized in call path and use JSStackFrame::flags to indicate whether there is or is not an imacpc. |
Method-jit changes
- PIC for fast natives calls
- PIC/fast path for interpreted inline call