the GC pauses when using GHC have seldom been a serious issue in most of our projects at Tweag I/O. We do also have some projects with special requirements, however (strong synchrony between many machines that block frequently). For those the GC pauses are indeed a problem. And like most non-trivial problems, it's a combination of multiple solutions that'll help us reduce or eliminate these long pauses.

The first line of work involves hacks to the GC. Making the GC incremental would certainly be nice. Local heaps might help for some workloads, but it's no silver bullet, as Simon PJ writes below. I think it would be very illuminating if Simon M or whoever else worked on early experiments regarding local heaps could post a detailed writeup as to what made the "complexity of the implementation extremely daunting" and the tradeoffs involved. Or a link there already is one. :)

As Ben alluded to earlier and as Reddit discovered some weeks ago, as part of another line of work, we are donating some ongoing effort to help with the problem by simply taking out some objects from the GC managed heap. Objects that the GC just doesn't have to deal with at all (either because allocated elsewhere or not at all, thanks to fusion) can relieve the pressure on the GC. But quite apart from our effort here, which does involve an extension to the type system to enable the programmer to make more of her/his intent clear to the compiler, I think the compact regions work that will be part of 8.2 is already a great step forward. It requires some programmer assistance, but if it's GC pause times you're wrestling with, chances are you have a very hard use case indeed so providing that assistance is likely easier than most other things you'll have to deal with.

Best,