On Sat, Sep 17, 2011 at 1:38 AM, Jesse Schalken wrote:

There might be a way to do it, I don't know, but this sounds like an XYhttp://www.perlmonks.org/index.pl?node_id=542341 problem http://mywiki.wooledge.org/XyProblem. Can I ask what you're trying to achieve by doing this, or is it just out of curiosity regarding how much garbage is created? (It's a lot, by the way. Since the only thing a purely functional program can do is create data and read data (as opposed to create, read and update in an impure program) I imagine a purely functional program without GC would hit OOM very, very quickly.)

Sure. I'm writing a server that serves a number of long-lived TCP connections. The clients can be served mostly independently; there is a bit of shared state among the different connections. I'd like to use the concurrency available to scale the server to handle a large number of clients. Ideally I would just use more cores to handle a larger number of clients. It seems that GC is the biggest obstacle to doing this. The problem seems to be that the current GC stops all the processors before performing a GC. With a large number of processors this becomes expensive, and I find that a program that has really high mutator productivity with one processor can get terrible productivity at 12 or more processors. Of course, it helps to reduce the allocation rate of the program, but even after being very careful about how much memory is allocated, GC still takes up a significant amount of time. So I was looking for a way to turn off GC altogether just as an experiment to see how the program would perform without all the GC pauses. --Andreas

On Thu, Sep 15, 2011 at 2:42 AM, Andreas Voellmy < andreas.voellmy@gmail.com> wrote:

...

Hi everyone, Is there a way to completely turn garbage collection off in the Haskell runtime system? I'm aware of the -A runtime option, but I'd like to completely turn it off, if possible. I'm OK with running the program until it runs out of memory, and I'm willing to recompile GHC if needed. Regards, Andreas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Sep 28, 2011 at 6:04 AM, Andreas Voellmy wrote:

Sure. I'm writing a server that serves a number of long-lived TCP connections.

How many are you looking at? (ROFLSCALEhttp://www.youtube.com/watch?v=majbJoD6fzo?) And how much activity? Do you need real-time responses?

It seems that GC is the biggest obstacle to doing this. The problem seems to be that the current GC stops all the processors before performing a GC.

Each OS thread gets its own bump-pointer nursery; minor collections of this nursery do not result in whole system pauses. This should be small enough to fit into a Core's cache (the default 512 kB is usually okay) so we can keep the entire nursery in cache while GC'ing it, keeping its cost close to that of stack. However, if you add an external pointer to large data or thunks in the nursery - e.g. by mutating a shared IORef - you can undermine the benefits of the nursery. It might be worth trying to do more work without mutations, and try to force evaluation of data before writing it to a variable. The idea is to keep the nursery busy so that the second-generation collectors don't need to be. Controlling memory is also important. Use iteratees to help make guarantees about memory consumption. Ideally, you can keep each TCP connection under some fixed live space cost - e.g. 2-4 MB. This keeps GCs small and cheap, and also allows the entire thread to fit into the CPU's larger caches, thus reducing scheduling and evaluation costs. Indeed, controlling memory is the most important thing you should do to reduce GC costs and improve performance. GC only touches live memory. Avoiding allocations is much less important than controlling amount of live memory. Regards, Dave

Thank you for the clarification. I had read those papers, but I was under the impression that it was something already part of GHC 7. Regards, Dave On Thu, Sep 29, 2011 at 8:45 PM, austin seipp wrote:

On Thu, Sep 29, 2011 at 3:14 PM, David Barbour 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