| |||||||||||||
|
| |||||||||||||
Not just GCNot just GCPosted Sep 15, 2009 20:07 UTC (Tue) by solidsnack (guest, #60840)In reply to: Not just GC by TomMD Parent article: Writing kernel modules in Haskell
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.
(Log in to post comments)
|
|
||||||||||||