... | ... | @@ -49,4 +49,4 @@ Slop can arise for two reasons: |
|
|
We avoid the problem for heap profiling? by arranging that we only ever do a census on a newly garbage-collected heap, which has no slop in it (the garbage collector never leaves slop between objects in the heap).
|
|
|
|
|
|
|
|
|
Slop does arise due to updates and black holes during normal execution, and GHC does not attempt to avoid it (because avoiding or filling slop during an update is costly). However, if we're doing [sanity checking](commentary/rts/sanity), then we need to arrange that slop is clearly marked: so in a `DEBUG` version of the RTS (see [RTS configurations](commentary/rts/config)) the update code and the blackhole code both arrange to fill slop with zeros: see the `FILL_SLOP` macro in [rts/Updates.h](/trac/ghc/browser/ghc/rts/Updates.h). Hence sanity checking only works with a `DEBUG` version of the RTS. |
|
|
Slop does arise due to updates and black holes during normal execution, and GHC does not attempt to avoid it (because avoiding or filling slop during an update is costly). However, if we're doing [sanity checking](commentary/rts/sanity), then we need to arrange that slop is clearly marked: so in a `DEBUG` version of the RTS (see [RTS configurations](commentary/rts/config)) the update code and the blackhole code both arrange to fill slop with zeros: see the `FILL_SLOP` macro in [rts/Updates.h](/ghc/ghc/tree/master/ghc/rts/Updates.h). Hence sanity checking only works with a `DEBUG` version of the RTS. |