History log of /dalvik/vm/Debugger.h
Revision Date Author Comments
375fb116bcb817b37509ab579dbd55cdbb765cbf 15-Jun-2011 Carl Shapiro <cshapiro@google.com> Normalize the include guard style.

An leading underscore followed by a capital letter is a reserved
name space in C and C++.

This change also moves any #include directives within the include
guard in some of the compiler/codegen/arm header files.

Change-Id: I9715e2c5301699d31886e61d0fe6e29483555a2a
d862faa2ceae186da5518607505eb942d634ced9 28-Apr-2011 Carl Shapiro <cshapiro@google.com> Get rid of uneeded extern, enum, typedef and struct qualifiers.

Change-Id: I236c5a1553a51f82c9bc3eaaab042046c854d3b4
ae188c676c681e47a93ade7fdf0144099b470e03 08-Apr-2011 Carl Shapiro <cshapiro@google.com> Compile the garbage collector and heap profiler as C++.

Change-Id: I25d8fa821987a3dd6d7109d07fd42dbf2fe0e589
9a3147c7412f4794434b4c2604aa2ba784867774 03-Mar-2011 buzbee <buzbee@google.com> Interpreter restructuring

This is a restructuring of the Dalvik ARM and x86 interpreters:

o Combine the old portstd and portdbg interpreters into a single
portable interpreter.
o Add debug/profiling support to the fast (mterp) interpreters.
o Delete old mechansim of switching between interpreters. Now, once
you choose an interpreter at startup, you stick with it.
o Allow JIT to co-exist with profiling & debugging (necessary for
first-class support of debugging with the JIT active).
o Adds single-step capability to the fast assembly interpreters without
slowing them down (and, in fact, measurably improves their performance).
o Remove old "polling for safe point" mechanism. Breakouts now achieved
via modifying base of interpreter handler table.
o Simplify interpeter control mechanism.
o Allow thread-granularity control for profiling & debugging

The primary motivation behind this change was to improve the responsiveness
of debugging and profiling and to make it easier to add new debugging and
profiling capabilities in the future. Instead of always bailing out to the
slow debug portable interpreter, we can now stay in the fast interpreter.

A nice side effect of the change is that the fast interpreters
got a healthy speed boost because we were able to replace the
polling safepoint check that involved a dozen or so instructions
with a single table-base reload. When combined with the two earlier CLs
related to this restructuring, we show a 5.6% performance improvement
using libdvm_interp.so on the Checkers benchmark relative to Honeycomb.

Change-Id: I8d37e866b3618def4e582fc73f1cf69ffe428f3c
0970976b0e980be00424f93a69c2bc13ca3131f3 18-Mar-2011 Andy McFadden <fadden@android.com> Fix up some JDWP stuff

Notably:
- Claim to know about synthetic attributes (canGetSyntheticAttribute).
Set an appropriate flag in the access flags of fields and methods.
(Makes no difference that I can see in Eclipse.)
- Stop making copies of descriptor strings. That ceased to be necessary
after they were normalized in DEX (pre-1.0).
- Correct object type determination, especially w.r.t. the specially-
tagged types (strings, threads, classloaders, etc).
- Handle a FIELD_ONLY mod (not tested).
- Added a bit of debugging stuff.

Change-Id: I5651b5b76d904a9edbd051e039423795faaa1650
cb3081f675109049e63380170b60871e8275f9a8 14-Jan-2011 buzbee <buzbee@google.com> Consolidate mterp's debug/profile/suspend control

This is a step towards full debug & profiling support in JIT'd code.
Previously, the interpreter made multiple distinct checks for pending
suspend requests, debugger and profiler checks at each safe point.
This CL moves the individual controls into a single control word,
significantly speeding up the safe-point check code path in the common
fast case.

In short, any time some VM component wants control to break at a safe
point it will set a bit in gDvm.interpBreak, which will be examined
at the safe point check in footer.S. In the old code, the safe point
check consisted of 11 instructions (including 6 loads). The new sequence
is 6 instructions (4 loads - two of which are needed and two are
speculative to fill otherwise stalling slots).

This code path is hot enough in the interpreter that we actually see
some measureable speedups in benchmarks. The old sieve benchmark
improves from 252 to 256 (~1.5%).

As part of the change, global debuggerActive and activeProfilers variables
have been eliminated as redundant. Note also that there is a subtle
change in thread suspension. Thread suspend request counts are kept on
a per-thread basis, and previously each thread would only examine its own
suspend count. With this change, a bit has been allocated in interpBreak
to signify that at least one suspend request is active across all
threads. This bit is treated as "some thread is supposed to
suspend, check to see if it's me".

Change-Id: I527dc918f58d1486ef3324136080ef541a775ba8
884cd427f504a6e105059199c3eeadd51a8b9c6e 19-Jul-2010 Andy McFadden <fadden@android.com> Implement JDWP ArrayType.NewInstance.

With this, you can go into the Eclipse "Display" view and evaluate
"new byte[5]" to get "(byte[]) [0, 0, 0, 0, 0]".

Change-Id: Id110c5701a9de12222760be6623585b5f7e28023
0171812e59e2520a4345b9bbadd4f7afa0a1de16 23-Jan-2010 Andy McFadden <fadden@android.com> Add streaming method profiling support.

The goal is to allow DDMS to start/stop method profiling in apps that
don't have permission to write to /sdcard. Instead of writing the
profiling data to disk and then pulling it off, we just blast the whole
thing straight from memory.

This includes:

- New method tracing start call (startMethodTracingDdms).
- Rearrangement of existing VMDebug method tracing calls for sanity.
- Addition of "vector" chunk send function, with corresponding
update to the JDWP transport function.
- Reshuffled the method trace start interlock, which seemed racy.
- Post new method-trace-profiling-streaming feature to DDMS.

Also:

- Added an internal exception-throw function that allows a printf
format string, so we can put useful detail into exception messages.

For bug 2160407.
c6e64ea32a7732e98975e37c5f8545c652a41ac8 05-Dec-2009 Andy McFadden <fadden@android.com> Don't assume debugger wants all exceptions.

The JDWP implementation in the VM keeps a list of the objects that the
debugger knows about, and prevents the GC from collecting them (which
isn't strictly necessary, but it's a whole lot easier than doing it
right). Because of the way it's implemented, it actually ended up
keeping track of all thrown exceptions, even if the debugger wasn't
interested in hearing about them.

With this change we now do a "late" registration of the exception
object, preventing exception-happy code from filling memory when the
debugger is attached.
96516932f1557d8f48a8b2dbbb885af01a11ef6e 29-Oct-2009 Andy McFadden <fadden@android.com> Change the way breakpoints work.

This replaces the breakpoint mechanism with a more efficient approach.
We now insert breakpoint instructions into the bytecode stream instead of
maintaining a table. This requires mapping DEX files as private instead
of shared, which allows copy-on-write to work. mprotect() is used to
guard the pages against inadvertent writes.

Unused opcode EC is now OP_BREAKPOINT. It's not recognized by dexdump or
any interpreter except portdbg, but it can be encountered by the bytecode
verifier (the debugger can request breakpoints in unverified code).
Breakpoint changes are blocked while the verifier runs to avoid races.

This eliminates method->debugBreakpointCount, which is no longer needed.
(Also, it clashed with LinearAlloc's read-only mode.)

The deferred verification error mechanism was using a code-copying
approach to modify the bytecode stream. That has been changed to use
the same copy-on-write modification mechanism.

Also, normalized all PAGE_SIZE/PAGESIZE references to a single
SYSTEM_PAGE_SIZE define.

Simple Fibonacci computation test times (opal-eng):
JIT, no debugger: 10.6ms
Fast interp, no debugger: 36ms
Portable interp, no debugger: 43.8ms

ORIG debug interp, no breakpoints set: 458ms
ORIG debug interp, breakpoint set nearby: 697ms

NEW debug interp, no breakpoints set: 341ms
NEW debug interp, breakpoints set nearby: 341ms

Where "nearby" means there's a breakpoint in the method doing the
computation that isn't actually hit -- the VM had an optimization where
it flagged methods with breakpoints and skipped some of the processing
when possible.

The bottom line is that code should run noticeably faster while a
debugger is attached.
6ff3c8fde9623dadad726dbd5e1658585c321751 13-Oct-2009 Andy McFadden <fadden@android.com> Add JDWP ReferenceType.ClassObject handler.

For bug 2157236.
f50c6d57afb09f8ed9da179a8bc8b409279ef8a6 03-Oct-2009 Andy McFadden <fadden@android.com> Add implementation of JDWP ClassType.NewInstance

Add a handler for the ClassType.NewInstance request, and some bits of
plumbing to go with it.

For bug 2157236.
f6c387128427e121477c1b32ad35cdcaa5101ba3 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
f72d5de56a522ac3be03873bdde26f23a5eeeb3c 04-Mar-2009 The Android Open Source Project <initial-contribution@android.com> auto import from //depot/cupcake/@135843
2ad60cfc28e14ee8f0bb038720836a4696c478ad 21-Oct-2008 The Android Open Source Project <initial-contribution@android.com> Initial Contribution