Immix garbage collector as GSoC

[Thomas Schilling]

On 27 Feb 2009, at 15:57, Simon Marlow wrote:

> Felipe Lessa wrote:
>>
>> I've just subscribed to cvs-ghc because I saw Simon's proposal on
>> reddit[1] about the Immix GC. After reading the paper, I would like  
>> to
>> know if it is feasible to consider implementing it in a GSoC project.
>
> It's a feasible GSoC project (that's why I suggested it!).  Thomas  
> Schilling looked into it a little when he was here as an intern, he  
> might be able to tell you more.  I recall we discussed the details a  
> bit, but can't remember exactly what we concluded.  You should read  
> not just the PLDI paper, but also the tech report which I believe  
> has more detailed information about the implementation.

I agree that it should be possible to do this as a GSoC project.   
There are, however, quite a few unknowns regarding performance.  It's  
possible that the decisions taken in Immix may not be the best fit for  
GHC.  For example, GHC heap objects don't contain space for extra  
bits, however, Immix uses extra bits at least for the following:

  - Immix stores mark bits in the object header
  - Immix also marks objects as big (> 8k) in the object header.  GHC  
uses a similar distinction, but stores the bits somewhere else.  The  
paper also mentions using the JIT to constant fold certain expressions.

There are a lot more questions which Blackburn and McKinley answered  
for RVM through lots of benchmarking.  I would certainly recommend  
much, much measuring for GHC, too.  In particular, GHC's trace loop  
may be rather slow since it needs to examine many different object  
types.  The trace loop also uses a fixed-size buffer and reverts to a  
much(?) slower scheme when this buffer overflows.

Overall, I think there's certainly enough interesting work to be  
done.  GHC's GC is already quite similar to Immix, but has made  
different design decisions in several places.  Even if we only get a  
lot more numbers about the behaviour of GHC's GC, this would be a  
useful outcome.

Go ahead!

/ Thomas
--
Push the envelope.  Watch it bend.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20090227/280b1073/PGP.bin