[Haskell-cafe] Turn GC off

[austin seipp]

On Thu, Sep 29, 2011 at 3:14 PM, David Barbour <dmbarbour at gmail.com> wrote:
>
> minor collections of this nursery do not result in whole system pauses.

Yes, they do. GHC has a parallel garbage collector (so collection
pauses the mutator threads, and collects garbage -in parallel- on
multiple CPUs) but it in no way has a concurrent one. Every OS thread
has its own young-gen heap space, and the old-generation heap space is
shared amongst every CPU. But any young-gen GC will cause all mutator
threads to pause no matter what the state of the others is.

That said, Simon^2 has done research on this problem recently. They
recently published a paper about 'local' garbage collection for
individual OS threads, where every thread has its own, private
nursery, that may be collected independently of all other CPUs, which
promotes objects into the global heap when necessary for access from
other threads. The design is reminiscent of older work on the same
topic (thread-local heaps,) but adds a bunch of tasty work they did.

You can find this branch of GHC with 'local heaps' here, in the
local-gc branch of the git repository:

https://github.com/ghc/ghc/tree/local-gc

This new local collector branch is not, I repeat, not part of GHC and
hasn't been merged. It's not certain if it ever will be, I think. The
paper conclusion addresses the fact the scalability improvements as a
result of this new collector are nowhere near as dramatic as they had
hoped, and it's not certain the improvements they did get are worth
the substantial complexity increase. It doesn't address the old-gen GC
- any old-gen GCs still pause all mutator threads before continuing.
They do note however that this local allocation strategy could be
combined with a real concurrent/incremental GC for the old-generation,
which would help control pause times more over the whole lifetime of
an application.

You can find all the juicy details in their paper "Multicore garbage
collection with thread local heaps", located near the top of Simon's
webpage here:

http://research.microsoft.com/en-us/people/simonpj/

-- 
Regards,
Austin