Bug 122844
Summary: | Implement a cheaper and faster Debugger Running mode | ||
---|---|---|---|
Product: | WebKit | Reporter: | Mark Lam <mark.lam> |
Component: | JavaScriptCore | Assignee: | Mark Lam <mark.lam> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | fpizlo, ggaren, joepeck, mhahnenberg, msaboff, oliver, timothy, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 122847 |
Mark Lam
With https://bugs.webkit.org/show_bug.cgi?id=122836, when in the Debugger Running mode, the LLINT and baseline JIT generated code needs to call a slow path to check if the Debugger needs to switch to Stepping mode. We can do better. This is how:
1. In Running mode, only call the slow path for op_debug if the op_debug "needBreaks" flag is set i.e. we need to handle a breakpoint.
2. In Stepping mode, before taking a step, the Debugger should:
2.1 decorate the next op_debug instruction's needBreaks with a "isStepping" bit.
e.g bit 0 == have breakpoint set here, bit 1 == stepping to this bytecode.
2.2. for call opcodes, fix up the CallLinkInfo to force a call to the slow path.
2.2.1 in the call slow paths, decorate the first op_debug instruction's needBreaks flag with an "isStepping" bit.
2.3 when handling exceptions, decorate the exception handler's first op_debug instruction's needBreaks flag with an "isStepping" bit.
With this change, the debugger should be able to achieve approximately a 3x speed up over shipping Safari on the Octane benchmark.
Note: the DFG is still not enabled for the debugger i.e. the DFG will see the op_debug opcode and fail compilation.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/15232333>
Mark Lam
This work has been folded into <https://webkit.org/b/122836>.
*** This bug has been marked as a duplicate of bug 122836 ***