Changes between Version 8 and Version 9 of Commentary/Rts/HeapObjects

Timestamp:

09/07/06 04:06:08 (7 years ago)

Author:

simonmar

Comment:

--

Commentary/Rts/HeapObjects

@@ -83 +83 @@
 When {{{TABLES_NEXT_TO_CODE}}} is off, info tables get another field, {{{entry}}}, which points to the entry code.  In a generated object file, each symbol {{{X_info}}} representing an info table will have an associated symbol {{{X_entry}}} pointing to the entry code (in {{{TABLES_NEXT_TO_CODE}}}, the entry symbol is omitted to keep the size of symbol tables down).
 
+-----------
+
 == Types of Payload Layout ==
 
@@ -100 +102 @@
 The payload consists of a mixture of pointers and non-pointers, described by a bitmap.  There are two kinds of bitmap:
 
-  * ''small''
-  * ''large''
+'''Small bitmaps.''' A small bitmap fits into a single word (the layout word of the info table), and looks like this:
+
+|| Size (bits 0-4) || Bitmap (bits 5-31) ||
+
+(for a 64-bit word size, the size is given 6 bits instead of 5).  
+
+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)]].
+
 
 -----------