Control over the actions of the debugger originate in the same process as the debuggee. Debugger code runs in the same process as the debuggee.
Control over the actions of the debugger originate in a different process than the debuggee. Some or all of the debugger code runs in a different process than the debuggee.
Debugger uses mechanisms such a shared memory to access the state of the debuggee. No debugger code runs in the debuggee process. Standard native debuggers, like dbx, are of this type.
Debugger front-end runs in a different process than the debuggee. Some code runs in the same process as the debuggee, with the mission of communicating information between the out-proc front-end and the debuggee. This piece I have heard variously called "helper thread", "corner of the VM", "in-proc side of the debugger" and "debuggee's debug agent thread". The current jdb is of this type.
In-proc debuggers are probably not appropriate for general debuggers - for a variety of reasons including resource contention. They are however useful in some special cases. Supporting this type of debugging is not the "design center". But, if we can produce a design that enables this form of debugger, it will be a significant plus.
A pure out-proc debugger for the JavaTM programming language would, by nature, have dependencies on the VM implementation, the VM version, the debuggee platform and the debugger platform. For these reasons it is not a good choice as a java debugger.
This approach can be implemented in a VM and platform-independent manner. With proper design it should be possible to virtually eliminate resource contention.
Copyright © 1997 Sun
Microsystems, Inc. All Rights Reserved.
Please send comments to: java-debugger@javasoft.com |
![]() |