Bug 122844

Summary: Implement a cheaper and faster Debugger Running mode
Product: WebKit Reporter: Mark Lam <mark.lam>
Component: JavaScriptCoreAssignee: 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
Reported 2013-10-15 10:49:10 PDT
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
Radar WebKit Bug Importer
Comment 1 2013-10-15 10:49:18 PDT
Mark Lam
Comment 2 2014-01-22 10:10:34 PST
This work has been folded into <https://webkit.org/b/122836>. *** This bug has been marked as a duplicate of bug 122836 ***
Note You need to log in before you can comment on or make changes to this bug.