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


Ignore:
Timestamp:
Sep 7, 2006 11:01:14 AM (8 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 ==