Changes between Version 6 and Version 7 of Commentary/Rts/Storage/HeapObjects

Timestamp:

10/09/09 07:35:46 (4 years ago)

Author:

simonmar

Comment:

--

Commentary/Rts/Storage/HeapObjects

@@ -24 +24 @@
 == Heap Objects ==
 
-All heap objects have the same basic layout, embodied by the type {{{StgClosure}}} in [http://darcs.haskell.org/ghc/includes/Closures.h Closures.h].  The diagram below shows the layout of a heap object:
+All heap objects have the same basic layout, embodied by the type {{{StgClosure}}} in [http://darcs.haskell.org/ghc/includes/rts/storage/Closures.h Closures.h].  The diagram below shows the layout of a heap object:
 
 [[Image(heap-object.png)]]
 
-A heap object always begins with a ''header'', defined by {{{StgHeader}}} in [http://darcs.haskell.org/ghc/includes/Closures.h Closures.h]:
+A heap object always begins with a ''header'', defined by {{{StgHeader}}} in [http://darcs.haskell.org/ghc/includes/rts/storage/Closures.h Closures.h]:
 
 {{{
@@ -56 +56 @@
 == Info Tables ==
 
-The info table contains all the information that the runtime needs to know about the closure.  The layout of info tables is defined by {{{StgInfoTable}}} in [[GhcFile(includes/InfoTables.h)]].  The basic info table layout looks like this:
+The info table contains all the information that the runtime needs to know about the closure.  The layout of info tables is defined by {{{StgInfoTable}}} in [[GhcFile(includes/rts/storage/InfoTables.h)]].  The basic info table layout looks like this:
 
 [[Image(basic-itbl.png)]]
@@ -63 +63 @@
   
  * The ''closure type'' is a constant describing the kind of closure this is (function, thunk, constructor etc.).  All
-   the closure types are defined in [[GhcFile(includes/ClosureTypes.h)]], and many of them have corresponding C struct
-   definitions in [[GhcFile(includes/Closures.h)]].
+   the closure types are defined in [[GhcFile(includes/rts/storage/ClosureTypes.h)]], and many of them have corresponding C struct
+   definitions in [[GhcFile(includes/rts/storage/Closures.h)]].
 
  * The ''SRT bitmap'' field is used to support [wiki:Commentary/Rts/CAFs garbage collection of CAFs].
@@ -116 +116 @@
 The size field gives the size of the payload, and each bit of the bitmap is 1 if the corresponding word of payload contains a pointer to a live object.
 
-The macros {{{MK_BITMAP}}}, {{{BITMAP_SIZE}}}, and {{{BITMAP_BITS}}} in [[GhcFile(includes/InfoTables.h)]] provide ways to conveniently operate on small bitmaps.
-
-'''Large bitmaps.''' If the size of the stack frame is larger than the 27 words that a small bitmap can describe, then the fallback mechanism is the large bitmap.  A large bitmap is a separate structure, containing a single word size and a multi-word bitmap: see {{{StgLargeBitmap}}} in [[GhcFile(includes/InfoTables.h)]].
+The macros {{{MK_BITMAP}}}, {{{BITMAP_SIZE}}}, and {{{BITMAP_BITS}}} in [[GhcFile(includes/rts/storage/InfoTables.h)]] provide ways to conveniently operate on small bitmaps.
+
+'''Large bitmaps.''' If the size of the stack frame is larger than the 27 words that a small bitmap can describe, then the fallback mechanism is the large bitmap.  A large bitmap is a separate structure, containing a single word size and a multi-word bitmap: see {{{StgLargeBitmap}}} in [[GhcFile(includes/rts/storage/InfoTables.h)]].
 
 
@@ -139 +139 @@
 enough to be overwritten by a
 forwarding pointer ([[ref(Forwarding Pointers)]]) during GC.
-The minimum size of the payload is given by {{{MIN_PAYLOAD_SIZE}}} in [[GhcFile(includes/Constants.h)]].
+The minimum size of the payload is given by {{{MIN_PAYLOAD_SIZE}}} in [[GhcFile(includes/rts/Constants.h)]].
 
 === Static objects ===
@@ -154 +154 @@
 static variant of an object has compatible layout with the dynamic
 variant.  To access the static link field of a closure, use the
-{{{STATIC_LINK()}}} macro from [[GhcFile(includes/ClosureMacros.h)]].
+{{{STATIC_LINK()}}} macro from [[GhcFile(includes/rts/storage/ClosureMacros.h)]].
 
 -----------
@@ -401 +401 @@
 GHC keeps stacks contiguous, there are no "stack chunk" objects.  This is simpler, but means that when growing a stack we have to copy the old contents to a larger area (see {{{threadStackOverflow()}}} in [[GhcFile(rts/Schedule.c)]]).
 
-The TSO structure contains several fields.  For full details see [[GhcFile(includes/TSO.h)]].  Some of the more important fields are:
+The TSO structure contains several fields.  For full details see [[GhcFile(includes/rts/storage/TSO.h)]].  Some of the more important fields are:
 
  * ''link'': field for linking TSOs together in a list.  For example, the threads blocked on an {{{MVar}}} are kept in
@@ -413 +413 @@
      to its new location.
    * {{{ThreadComplete}}}: this thread has finished and can be garbage collected when it is unreachable.
- * ''why_blocked'': for a blocked thread, indicates why the thread is blocked.  See [[GhcFile(includes/Constants.h)]] for
+ * ''why_blocked'': for a blocked thread, indicates why the thread is blocked.  See [[GhcFile(includes/rts/Constants.h)]] for
    the list of possible values.
  * ''block_info'': for a blocked thread, gives more information about the reason for blockage, eg. when blocked on an