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


Ignore:
Timestamp:
Sep 7, 2006 11:03:47 AM (8 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}}},