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


Ignore:
Timestamp:
Oct 9, 2009 2:35:46 PM (6 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