JSStackFrame Evisceration: Difference between revisions
Jump to navigation
Jump to search
| Line 12: | Line 12: | ||
| '''Note''' | | '''Note''' | ||
|- | |- | ||
| [https://bugzilla.mozilla.org/show_bug.cgi?id=539144 argc/argv] | | [https://bugzilla.mozilla.org/show_bug.cgi?id=539144 argc/argv/fun/script/thisv] | ||
| 1.5 | | 1.5 | ||
| lw | | lw | ||
| Requires CallSegment (CallStack) changes, educate decompiler | | Requires CallSegment (CallStack) changes, educate decompiler | ||
|- | |- | ||
| ncode | | ncode | ||
Revision as of 19:40, 25 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/fun/script/thisv | 1.5 | lw | Requires CallSegment (CallStack) changes, educate decompiler |
| 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