sutton036

Update: Maoni Stephens of Microsoft, the author of this new "Background" garbage collector in .NET 4, has now reproduced the bug and acknowledged that we really are seeing GC pauses lasting several minutes. Whilst developing low latency software on .NET, we have discovered a serious bug in the .NET 4 concurrent workstation garbage collector that can cause applications to hang for up to several minutes at a time. On three of our machines the following simple C# program causes the GC to leak memory until none remains and a single mammoth GC cycle kicks in, stalling the program for several minutes (!) while 11Gb of heap is recycled: static void Main(string[] args) { var q = new System.Collections.Generic.Queue (); while (true) { q.Enqueue(0); if (q.Count > 1000000) q.Dequeue(); } } You need to compile for x64 on a 64-bit Windows OS with .NET 4 and run with the default (concurrent workstation) GC using the default (interactive) latency setting. Here's...

Simon Marlow of Microsoft Research recently published a blog post entitled First results from GHC's new garbage collector . As his beautiful graphs show so clearly, this is a first step towards concurrent garbage collection. The blog post describes this advancement entirely from the perspective of throughput because the ability to collect per-thread nursery generations independently removes some of the blocking that was wasting mutator time in the previous version. However, we believe that concurrent programming may become a killer application domain for Haskell and, in that context, latency can be critical. If GHC's garbage collector is made more concurrent, by allowing the old generation to be collected independently as well, then pause times could be greatly reduced and Haskell would have a considerable advantage over competing technologies like .NET. We have found that even the best-behaved .NET programs that allocate still suffer GC pauses of around 20ms, over an order of ...

In this era of multicore computing, garbage collectors need to allow user threads (aka mutators ) to run in parallel on separate cores simultaneously in order to facilitate efficient shared memory parallel programming. There are two relevant phrases from garbage collection terminology here: Parallel GC means the garbage collector itself has been parallelised in order to speed up garbage collections. For example, a stop-the-world collector might traverse the heap in parallel when marking in an attempt to reduce pause times. Concurrent GC means the garbage collector runs at the same time as the user threads (aka mutators ). For example, Dijkstra's algorithm and derivatives like Doligez-Leroy use fine-grained synchronization to keep a concurrently-running collector apprised of the constantly-changing heap topology. However, we are talking about neither parallel GC nor concurrent GC but, rather, the simpler challenge of just allowing mutators to run in parallel. In the absence of any...