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


Ignore:
Timestamp:
Sep 7, 2006 11:06:08 AM (9 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Rts/HeapObjects

    v8 v9  
    8383When {{{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).
    8484
     85-----------
     86
    8587== Types of Payload Layout ==
    8688
     
    100102The payload consists of a mixture of pointers and non-pointers, described by a bitmap.  There are two kinds of bitmap:
    101103
    102   * ''small''
    103   * ''large''
     104'''Small bitmaps.''' A small bitmap fits into a single word (the layout word of the info table), and looks like this:
     105
     106|| Size (bits 0-4) || Bitmap (bits 5-31) ||
     107
     108(for a 64-bit word size, the size is given 6 bits instead of 5). 
     109
     110The 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.
     111
     112The macros {{{MK_BITMAP}}}, {{{BITMAP_SIZE}}}, and {{{BITMAP_BITS}}} in [[GhcFile(includes/InfoTables.h)]] provide ways to conveniently operate on small bitmaps.
     113
     114'''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)]].
     115
    104116
    105117-----------