Home | History | Annotate | Download | only in jdwp

Lines Matching full:debugger

26 #include "debugger.h"
35 The event add/remove stuff usually happens from the debugger thread,
36 in response to requests from the debugger, but can also happen as the
46 We can have serialization issues when we post an event to the debugger.
48 myself" message to the debugger. Before it manages to suspend itself, the
49 debugger's response ("not interested, resume thread") arrives and is
52 This means that, after posting an event to the debugger, we need to wait
54 before processing any additional requests from the debugger. While doing
63 - Post the event to the debugger.
643 * Write the header into the buffer and send the packet off to the debugger.
663 * Tell the debugger that we have finished initializing. This is always
664 * sent, even if the debugger hasn't requested it.
732 * while handling a request from the debugger. Don't fire breakpoints
742 * The debugger variable display tab may invoke the interpreter to format
744 * traps while working on behalf of the debugger.
747 * suspend on a breakpoint while the debugger is still waiting for its
866 * Send a polite "VM is dying" message to the debugger.
892 * up the debugger.
907 /* don't try to post an exception caused by the debugger */
974 /* suppress class prep caused by debugger */
996 * JDWP says that, for a class prep in the debugger thread, we
1000 VLOG(jdwp) << " NOTE: class prepare in debugger thread!";
1034 * other debugger traffic, and can't suspend the VM, so we skip all of