Immix garbage collector as GSoC
nominolo at googlemail.com
Fri Feb 27 13:15:50 EST 2009
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 about the Immix GC. After reading the paper, I would like
>> 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
Push the envelope. Watch it bend.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 194 bytes
Desc: This is a digitally signed message part
Url : http://www.haskell.org/pipermail/cvs-ghc/attachments/20090227/280b1073/PGP.bin
More information about the Cvs-ghc