Hi Chris,
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,
--
Mathieu Boespflug
Founder at http://tweag.io.
On 17 October 2016 at 19:08, Christopher Allen
It'd be unfortunate if more companies trying out Haskell came to the same result: https://blog.pusher.com/latency-working-set-ghc-gc- pick-two/#comment-2866985345 (They gave up and rewrote the service in Golang)
Most of the state of the art I'm aware of (such as from Azul Systems) is from when I was using a JVM language, which isn't necessarily applicable for GHC.
I understand Marlow's thread-local heaps experiment circa 7.2/7.4 was abandoned because it penalized performance too much. Does the impression that there isn't the labor to maintain two GCs still hold? It seems like thread-local heaps would be pervasive.
Does anyone know what could be done in GHC itself to improve this situation? Stop-the-world is pretty painful when the otherwise excellent concurrency primitives are much of why you're using Haskell.
--- Chris Allen _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs