Changes between Version 2 and Version 3 of Commentary/Rts/Stack


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

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Rts/Stack

    v2 v3  
    2727Unlike heap objects which mainly have "pointers first" layout, in a stack frame the pointers and non-pointers are intermingled.  This is so that we can support "stack stubbing" whereby a live variable stored on the stack can be later marked as dead simply by pushing a new stack frame that identifies that slot as containing a non-pointer, so the GC will not follow it.
    2828
    29 The stack frame describes the pointerhood of each word in the payload by means of a bitmap.  There are two kinds of bitmap: ''small'' and ''large'':
     29Stack frames therefore have [wiki:Commentary/Rts/HeapObjects#Bitmaplayout bitmap layout].
    3030
    31 === Small bitmaps ===
    32 
    33 A small bitmap fits into a single word (the layout word of the info table), and looks like this:
    34 
    35 || Size (bits 0-4) || Bitmap (bits 5-31) ||
    36 
    37 (for a 64-bit word size, the size is given 6 bits instead of 5). 
    38 
    39 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.
    40 
    41 The macros {{{MK_BITMAP}}}, {{{BITMAP_SIZE}}}, and {{{BITMAP_BITS}}} in [[GhcFile(includes/InfoTables.h)]] provide ways to conveniently operate on small bitmaps.
    42 
    43 === Large bitmaps ===
    44 
    45 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)]].
    46 
    47 == Stack Frames ==
     31== Kinds of Stack Frame ==
    4832
    4933{{{RET_BCO}}},