Not just GC [LWN.net]

Not just GC

Posted Sep 13, 2009 22:44 UTC (Sun) by salimma (subscriber, #34460)
In reply to: Writing kernel modules in Haskell by Baylink
Parent article: Writing kernel modules in Haskell

.. it's worse than that: while Haskell supports SMP, its garbage-collector is still single-threaded -- http://www.haskell.org/ghc/docs/latest/html/users_guide/u...

A friend of mine worked on it a couple of summers ago at MSR Cambridge; I guess it's not quite done yet.

(Log in to post comments)

Not just GC

Posted Sep 14, 2009 17:20 UTC (Mon) by TomMD (guest, #56998) [Link]

No - you can use a parallel GC with GHC. SimonM has some publications on the details they implemented [1]. Never-the-less, the RTS used by House (which I used as a base) is single threaded, so of coarse the GC will be. To get a hold of multiple processors in the Kernel for any stop-the-world GC would not be very cool.

[1] http://www.haskell.org/~simonmar/bib/bib.html

Not just GC

Posted Sep 15, 2009 20:07 UTC (Tue) by solidsnack (guest, #60840) [Link]

Last I checked, the multicore collector for GHC was a parallel, stop-the-world collector. From Parallel Generational-Copying Garbage Collection with a Block-Structured Heap (2008):

We focus on parallel, rather than concurrent, collection. In a concurrent collector the mutator and collector run at the same time, whereas we only consider garbage collecting in parallel while the mutator is paused.

Parallel GC doesn't directly address the problem of intermittent, hard to control GC latency. For soft real-time apps like the kernel, file systems, games and network services, this is less than ideal.

I haven't measured typical pause times for Haskell programs. Non-stop Haskell (2000) mentions average pause times of between 1 and 117 milliseconds on various benchmarks with GHC 4's standard collector. Their concurrent garbage collector, implemented for GHC 4, is able to get sub-millisecond average pause times (and, for a price, average pauses of much less than a millisecond).

Another interesting piece of work in this vein is John Meacham's region inference for JHC (2009). The idea is that some (all?) Haskell programs can have their memory statically allocated if that's desired; then you don't need a garbage collector.

I'd be very unhappy with my kernel module if it froze for 100ms; depending on what you're doing, even 1ms might be too much. On the other hand, strongly typed, purely functional programming is the way of the future and a lot of good work is being done to sort this stuff out.