Update docs for debugger change.

Update notes re: breakpoint implementation (changed Oct 28, 96516932).

1 files changed, 7 insertions, 8 deletions

diff --git a/docs/debugger.html b/docs/debugger.html
index 523c7123d..033eeb62d 100644
--- a/docs/debugger.html
+++ b/docs/debugger.html
@@ -55,14 +55,13 @@ A connection from DDMS alone doesn't result in a change in VM behavior,
 but when the VM sees debugger packets it allocates additional data
 structures and may switch to a different implementation of the interpreter.
 </p><p>
-Because Dalvik maps bytecode into memory read-only, some common
-techniques are difficult to implement without allocating additional memory.
-For example, suppose the debugger sets a breakpoint in a method.  The
-quick way to handle this is to insert a breakpoint instruction directly
-into the code.  When the instruction is reached, the breakpoint handler
-engages.  Without this, it's necessary to perform an "is there a breakpoint
-here" scan.  Even with some optimizations, the debug-enabled interpreter
-is much slower than the regular interpreter (perhaps 5x).
+Pre-Flan implementations of the Dalvik VM used read-only memory mappings
+for all bytecode, which made it necessary to scan for breakpoints by
+comparing the program counter to a set of addresses.  In Flan this was
+changed to allow insertion of breakpoint opcodes.  This allows the VM
+to execute code more quickly, and does away with the hardcoded limit
+of 20 breakpoints.  Even with this change, however, the debug-enabled
+interpreter is much slower than the regular interpreter (perhaps 5x).
 </p><p>
 The JDWP protocol is stateless, so the VM handles individual debugger
 requests as they arrive, and posts events to the debugger as they happen.