Changes between Version 3 and Version 4 of Commentary/Rts/Storage/GC


Ignore:
Timestamp:
Dec 4, 2009 12:34:14 PM (5 years ago)
Author:
simonmar
Comment:

--

Legend:

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

    v3 v4  
    2626 * The heap grows on demand.  This is straightforwardly implemented by basing the whole storage manager on a [wiki:Commentary/Rts/Storage/BlockAlloc block allocator]. 
    2727 
    28  * Aging: objects can be aged within a generation, to avoid premature promotion.  See [wiki:Commentary/Rts/Storage/GC/Aging].  In GHC 6.12 and earlier this was implemented by having each generation consist of a runtime-tunable number of ''steps'', so objects would be moved through the list of steps before being promoted to the next highest generation.  We found that having 2 steps was almost always the best ''integral'' number of steps, but GHC 6.12 did not support a fractional number of steps.  In GHC 6.13 and later, the concept of steps was removed.  Aging is still supported, by having each block point to the generation to which objects in that block should be promoted; this lets us provide any fractional number of steps between 1 and 2, while eliminating the infrastructural overhead of steps. 
     28 * Aging: objects can be aged within a generation, to avoid premature promotion.  See [wiki:Commentary/Rts/Storage/GC/Aging]. 
    2929 
    3030 * The heap collection policy is runtime-tunable.  You select how large a generation gets before it is collected using the `+RTS -F<n> -RTS` option, where `<n>` is a factor of the generation's size the last time it was collected.  The default value is 2, that is a generation is allowed to double in size before being collected.