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


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

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Rts/HeapObjects

    v7 v8  
    6464 * The ''SRT bitmap'' field is used to support [wiki:Commentary/Rts/CAFs garbage collection of CAFs].
    6565
    66  * The ''layout'' field describes the layout of the closure for the garbage collector.  The GC needs to know
    67    two things: how many words there are in the payload, and which of those words are pointers.  There are various ways
    68    in which a closure may be laid out:
    69    * ''fixed layout'': the layout is fixed by the closure type, the layout field in the info table is ignored.  eg.
    70      MUT_VAR closures have fixed layout.
    71    * ''pointers first'': the payload consists of zero or more pointers followed by zero or more non-pointers.
    72      This is the most common layout: constructors, functions and thunks use this layout.  The  layout field contains
    73      two half-word-sized fields:
    74      * Number of pointers
    75      * Number of non-pointers
    76    * ''bitmap'': the layout is described by a bitmap (see [wiki:Commentary/Rts/HeapObjects#Bitmaps bitmaps], below).  Stack frames generally have bitmap layout.
     66 * The ''layout'' field describes the layout of the payload for the garbage collector, and is described in more
     67   detail in [wiki:Commentary/Rts/HeapObjects#TypesofPayloadLayout Types of Payload Layout] below.
    7768
    7869 * The ''entry code'' for the closure is usually the code that will ''evaluate'' the closure.  There is one exception:
     
    9182
    9283When {{{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).
     84
     85== Types of Payload Layout ==
     86
     87The GC needs to know two things about the payload of a heap object: how many words it contains, and which of those words are pointers.  There are two basic kinds of layout for the payload: ''pointers-first'' and ''bitmap''.  Which of these kinds of layout is being used is a property of the ''closure type'', so the GC first checks the closure type to determine how to interpret the layout field of the info table.
     88
     89=== Pointers-first layout ===
     90
     91The payload consists of zero or more pointers followed by zero or more non-pointers.
     92This is the most common layout: constructors, functions and thunks use this layout.  The  layout field contains
     93two half-word-sized fields:
     94
     95  * Number of pointers
     96  * Number of non-pointers
     97
     98=== Bitmap layout ===
     99
     100The payload consists of a mixture of pointers and non-pointers, described by a bitmap.  There are two kinds of bitmap:
     101
     102  * ''small''
     103  * ''large''
    93104
    94105-----------
     
    405416
    406417{{{BLOCKED_FETCH}}}, {{{FETCH_ME}}}, {{{FETCH_ME_BQ}}}, {{{RBH}}}, {{{REMOTE_REF}}}
    407 
    408 == Bitmaps ==