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


Ignore:
Timestamp:
Oct 9, 2009 2:35:46 PM (5 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Rts/Storage/HeapObjects

    v6 v7  
    2424== Heap Objects == 
    2525 
    26 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: 
     26All 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: 
    2727 
    2828[[Image(heap-object.png)]] 
    2929 
    30 A heap object always begins with a ''header'', defined by {{{StgHeader}}} in [http://darcs.haskell.org/ghc/includes/Closures.h Closures.h]: 
     30A heap object always begins with a ''header'', defined by {{{StgHeader}}} in [http://darcs.haskell.org/ghc/includes/rts/storage/Closures.h Closures.h]: 
    3131 
    3232{{{ 
     
    5656== Info Tables == 
    5757 
    58 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: 
     58The 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: 
    5959 
    6060[[Image(basic-itbl.png)]] 
     
    6363   
    6464 * The ''closure type'' is a constant describing the kind of closure this is (function, thunk, constructor etc.).  All 
    65    the closure types are defined in [[GhcFile(includes/ClosureTypes.h)]], and many of them have corresponding C struct 
    66    definitions in [[GhcFile(includes/Closures.h)]]. 
     65   the closure types are defined in [[GhcFile(includes/rts/storage/ClosureTypes.h)]], and many of them have corresponding C struct 
     66   definitions in [[GhcFile(includes/rts/storage/Closures.h)]]. 
    6767 
    6868 * The ''SRT bitmap'' field is used to support [wiki:Commentary/Rts/CAFs garbage collection of CAFs]. 
     
    116116The 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. 
    117117 
    118 The macros {{{MK_BITMAP}}}, {{{BITMAP_SIZE}}}, and {{{BITMAP_BITS}}} in [[GhcFile(includes/InfoTables.h)]] provide ways to conveniently operate on small bitmaps. 
    119  
    120 '''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)]]. 
     118The macros {{{MK_BITMAP}}}, {{{BITMAP_SIZE}}}, and {{{BITMAP_BITS}}} in [[GhcFile(includes/rts/storage/InfoTables.h)]] provide ways to conveniently operate on small bitmaps. 
     119 
     120'''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)]]. 
    121121 
    122122 
     
    139139enough to be overwritten by a 
    140140forwarding pointer ([[ref(Forwarding Pointers)]]) during GC. 
    141 The minimum size of the payload is given by {{{MIN_PAYLOAD_SIZE}}} in [[GhcFile(includes/Constants.h)]]. 
     141The minimum size of the payload is given by {{{MIN_PAYLOAD_SIZE}}} in [[GhcFile(includes/rts/Constants.h)]]. 
    142142 
    143143=== Static objects === 
     
    154154static variant of an object has compatible layout with the dynamic 
    155155variant.  To access the static link field of a closure, use the 
    156 {{{STATIC_LINK()}}} macro from [[GhcFile(includes/ClosureMacros.h)]]. 
     156{{{STATIC_LINK()}}} macro from [[GhcFile(includes/rts/storage/ClosureMacros.h)]]. 
    157157 
    158158----------- 
     
    401401GHC 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)]]). 
    402402 
    403 The TSO structure contains several fields.  For full details see [[GhcFile(includes/TSO.h)]].  Some of the more important fields are: 
     403The TSO structure contains several fields.  For full details see [[GhcFile(includes/rts/storage/TSO.h)]].  Some of the more important fields are: 
    404404 
    405405 * ''link'': field for linking TSOs together in a list.  For example, the threads blocked on an {{{MVar}}} are kept in 
     
    413413     to its new location. 
    414414   * {{{ThreadComplete}}}: this thread has finished and can be garbage collected when it is unreachable. 
    415  * ''why_blocked'': for a blocked thread, indicates why the thread is blocked.  See [[GhcFile(includes/Constants.h)]] for 
     415 * ''why_blocked'': for a blocked thread, indicates why the thread is blocked.  See [[GhcFile(includes/rts/Constants.h)]] for 
    416416   the list of possible values. 
    417417 * ''block_info'': for a blocked thread, gives more information about the reason for blockage, eg. when blocked on an