Platform/JSDebugv2: Difference between revisions

Jump to navigation Jump to search
New section: design principles
(New section: design principles)
Line 47: Line 47:


</ul>
</ul>
= Design Principles for <b>js::dbg2</b> =
<ul>
<li><b>js::dbg2 must support remote debugging.</b> Using a protocol
resembling the [http://code.google.com/p/v8/wiki/DebuggerProtocol V8
debugger protocol], js::dbg2 should allow the debugger's user interface to
run in a separate process, perhaps even on a separate machine, from the
debuggee. This allows us to debug on mobile devices and worker threads, and
increases the segregation of debugger and debuggee.
<li><b>js::dbg2 will support cross-thread debugging via remote
debugging.</b> The "server" for the remote protocol will be lightweight
enough that each thread will be able to run its own instance. The debugger
user interface will then simply be responsible for being a client to
multiple debug servers at once. All cross-thread interaction will be
mediated by the remote protocol, greatly simplifying js::dbg2's
implementation.
<p>(Note that some operations are inherently cross-thread: enumerating
currently running threads; thread creation notifications; the initial
attachment of the debugger to a thread. But once a thread has been attached
to, all subsequent communication is via the remote protocol.)</p>
<li><b>js::dbg2 must operate at the JavaScript source language level.</b>
SpiderMonkey's current debugging interfaces (jsdbgapi and jsd) are built
around the specifics of the bytecode engine. While that interface can be
supported in JägerMonkey and TraceMonkey as well, this is a needless
mismatch in abstraction level. Supporting js::dbg2 should require
JägerMonkey and TraceMonkey to relate the state of the running compiled
program directly to the original JavaScript program --- not to the state of
imaginary bytecode, which is then related to the original JavaScript.
</ul>


= Event Handlers and Spheres =
= Event Handlers and Spheres =
Confirmed users
496

edits

Navigation menu