Both concurrent GC and incremental GC tend to add overheads to the
mutator, because they need a read barrier. There was an incremental
GC for GHC once [1], taking advantage of the built-in read barrier
that we have whereby most closures are "entered"
Was there a specific reason why that GC implementation chose to use a
read barrier rather than a write barrier? I would have thought that
in general, a write barrier is cheaper to implement. Doesn't ghc
update fewer thunks than it enters?
Regards,
Malcolm
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe