[Haskell-cafe] Re: Real-time garbage collection for Haskell

[Simon Marlow]

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