On 02/03/2010 14:11, Malcolm Wallace wrote:
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?
If the GC wants to move objects, then a read barrier is needed in order
to figure out whether you're looking at an object that has moved or not.
If you don't move objects, then you can get away with only a write
barrier - the write barrier is needed so that you can remember which
objects or fields might need to be re-scanned because they were mutated.
The choice made in the Non-stop Haskell paper was to take advantage of
the existing read barrier so that we could move objects.
Some schemes copy objects rather than move them, and then you can get
away without a read barrier, but then your write barrier has to keep the
two copies in sync. Tradeoffs are everywhere, GC is a tricky business!
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
