... | ... | @@ -13,4 +13,4 @@ We gave some performance results for this technique in [Runtime Support for Mult |
|
|
Eager promotion works like this. To do eager promtion, the scavenger sets the flag `gct->eager_promotion` (it can leave the flag set when scavenging multiple objects, this is the usual way), and `gct->evac_gen` is set to the generation to which to eagerly promote objects. The `evacuate` function will try to move each live object into `gct->evac_gen` or a higher generation if possible, and set `gct->failed_to_evac` if it fails (see [Commentary/Rts/Storage/GC/RememberedSets](commentary/rts/storage/gc/remembered-sets)). It may fail if the target object has already been moved: we can't move an object twice during GC, because there may be other pointers already updated to point to the new location. It may also fail if the object is in a generation that is not being collected during this cycle.
|
|
|
|
|
|
|
|
|
Objects which are repeatedly mutable should not be subject to eager promotion, because the object may be mutated again, so eagerly promoting the objects it points to may lead to retaining garbage unnecessarily. Hence, when we are scavenging a mutable object (see [rts/sm/Scav.c](https://gitlab.haskell.org/ghc/ghc/tree/master/ghc/rts/sm/Scav.c)), we temporarily turn off `gct->eager_promotion`. |
|
|
Objects which are repeatedly mutable should not be subject to eager promotion, because the object may be mutated again, so eagerly promoting the objects it points to may lead to retaining garbage unnecessarily. Hence, when we are scavenging a mutable object (see [rts/sm/Scav.c](https://gitlab.haskell.org/ghc/ghc/blob/master/rts/sm/Scav.c)), we temporarily turn off `gct->eager_promotion`. |