Changes between Version 6 and Version 7 of GhciDebugger

Timestamp:

10/25/06 04:10:55 (7 years ago)

Author:

mnislaih

Comment:

Added missing important information about dynamic breakpoints

GhciDebugger

@@ -1 @@
-= Work in Progress =
+
+[[PageOutline]]
+
 = Report of the implementation of the GHCi debugger =
 During the Summer of 2006 I have been working on this project sponsorized by the[http://code.google.com/soc Google SoC] initiative. My mentors were Simon Marlow and David Himmelstrup (lemmih).
@@ -168 +170 @@
 = Dynamic Breakpoints =
 The approach followed here has been the well known 'do the simplest thing that could possibly work'. We instrument the code with 'auto' breakpoints at event ''sites''. Currently event sites are code locations where names are bound, and statements:
- * let declarations
- * where declarations 
- * top level declarations 
- * case alternatives 
- * lambda abstractions
+ * Binding sites (top level, let/where local bindings, case alternatives, lambda abstractions, etc.)
  * do statements (any variant of them)
 
 The instrumentation is done at the desugarer too, which has been extended accordingly. We distinguish between 'auto' breakpoints, those introduced by the desugarer, and 'normal' breakpoints user created by using the `breakpoint` function directly.
+
+== The D in Dynamic Breakpoints ==
+When we instrument the code we insert a flavor of regular breakpoints which know about their site number. So when one of these is hit, ghci finds out whether that site is enabled and acts accordingly.
+GHCi thus stores a boolean matrix of enabled breakpoint sites. This scheme is realized in [http://darcs.haskell.org/SoC/ghc.debugger/compiler/main/Breakpoints.hs Breakpoints.hs]:
+{{{
+data BkptTable a  = BkptTable { 
+     breakpoints :: Map.Map a (UArray Int Bool)  -- *An array of breaks, indexed by site number
+   , sites       :: Map.Map a [[(SiteNumber, Int)]] -- *A list of lines, each line can have zero or more sites, which are annotated with a column number
+   }
+}}}
+
+Since this structure needs to be accessed every time a breakpoint is hit and is modified extremely few times in comparison, the goal is to have as fast access time as possible. Most of the overhead is due to this structure.
+It's too bad that I haven't explored alternative designs. (Using bits instead of Bools in the matrix? discard the matrix thing and use an IORef in every breakpoint? some clever trick using the FFI?). 
 
 == Overhead ==