What makes GHC's GC good for purely functional workloads?

[Antoine Latter]

On Wed, Nov 23, 2011 at 4:31 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 23/11/2011 04:09, Edward Z. Yang wrote:
>>
>> Apologies if this has been asked before.  In some ways
>> GHC's garbage collectors are very traditional, so I was
>> wondering what magic dust makes it do better in Haskelly
>> workloads (e.g. whereas you'd need to do a bit more work
>> in the JVM to make some allocation pattern play nice.)
>
> Our GC is generally tuned towards making allocation fast.  So we use
> bump-pointer allocation and allocate several objects at once, and we use
> generational GC where the default nursery size is small (about L2
> cache-sized).  Young-generation collections are very quick - on the order of
> 10us.  So we collect a lot of the garbage before it even hits main memory;
> this is also what makes GHC's GC scale reasonably well for parallel
> programs.
>
> On the other hand, our write barriers are more expensive than you'd
> typically find in a JVM, but they are more accurate: remembered set rather
> than card marking.  This is a good tradeoff because mutation is rare in
> Haskell.  The one exception is thunk update - there might be room for
> experimenting with a cheaper write barrier there.
>
> One thing I'm particularly proud of in our GC is the block layer.  All
> memory is managed in units of blocks (currently 4k, but that's just a
> constant you can change).  It makes everything a lot simpler, including
> parallel GC.  We have a paper about it:
>
> http://community.haskell.org/~simonmar/papers/parallel-gc.pdf
>

It sounds like the new "Garbage First" collector might be closer to
these goals than the older HotSpot JVM collectors:

http://labs.oracle.com/jtech/pubs/04-g1-paper-ismm.pdf

It was built with different goals, but the end result is that it (can)
focus on collecting garbage while its young.

The paper was written a few years before the first version shipped, so
I'm not sure how the implementation differs.

> Cheers,
>        Simon
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>