<div dir="ltr">Hi Chris,<div><br></div><div>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.</div><div><br></div><div>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. :)</div><div><br></div><div>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.</div><div><br></div><div>Best,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">--<br>Mathieu Boespflug<br>Founder at <a href="http://tweag.io" target="_blank">http://tweag.io</a>.</div></div>
<br><div class="gmail_quote">On 17 October 2016 at 19:08, Christopher Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It'd be unfortunate if more companies trying out Haskell came to the<br>
same result: <a href="https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/#comment-2866985345" rel="noreferrer" target="_blank">https://blog.pusher.com/<wbr>latency-working-set-ghc-gc-<wbr>pick-two/#comment-2866985345</a><br>
(They gave up and rewrote the service in Golang)<br>
<br>
Most of the state of the art I'm aware of (such as from Azul Systems)<br>
is from when I was using a JVM language, which isn't necessarily<br>
applicable for GHC.<br>
<br>
I understand Marlow's thread-local heaps experiment circa 7.2/7.4 was<br>
abandoned because it penalized performance too much. Does the<br>
impression that there isn't the labor to maintain two GCs still hold?<br>
It seems like thread-local heaps would be pervasive.<br>
<br>
Does anyone know what could be done in GHC itself to improve this<br>
situation? Stop-the-world is pretty painful when the otherwise<br>
excellent concurrency primitives are much of why you're using Haskell.<br>
<br>
--- Chris Allen<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>