<div dir="ltr">It will be awesome if we can spread the GC work instead of stopping the world for too long. I am a new entrant to the Haskell world but something similar to this was the first real problem (other than lazy IO) that I faced with GHC. While I was debugging I had to learn how the GC works to really understand what's going on. Then I learnt to always strive to keep the retained heap to the minimum possible. But sometimes the minimum possible could be a lot. This blog article was sort of a deja vu for me. It seems this is not a rare problem.<div><br></div><div>I guess, the compact regions technique as suggested by Ben can be used to workaround the problem but it sounds like it is application aware and users will have to discover the possibility of that solution, I might be mistaken though. If we want GHC to work smoothly for performance critical applications then we should perhaps find a cost effective way to solve this in an application transparent manner.</div><div><br></div><div>-harendra<br><div class="gmail_extra"><br><div class="gmail_quote">On 18 October 2016 at 18:33, Simon Peyton Jones via ghc-devs <span dir="ltr"><<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>| 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>
</span>I was optimistic about thread-local heaps, but while perf did improve a bit, the complexity of the implementation was extremely daunting. So we decided that the pain didn't justify the gain.<br>
<br>
I'm not sure it'd help much here, since the data is long-lived and might migrate into the global heap anyway.<br>
<br>
Most GCs rely on traversing live data. Here the live data is big. So really the only solution is to traverse it incrementally. You can still stop-the-world, but you have to be able to resume normal execution before GC is complete, thus smearing GC out into a series of slices, interleaved with (but not necessarily in parallel with) the main application.<br>
<br>
I believe the that the OCaml runtime now has such a GC. It'd be lovely to have one for GHC.<br>
<br>
But I defer to Simon M<br>
<br>
Simon<br>
<span><br>
| -----Original Message-----<br>
| From: ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haske<wbr>ll.org</a>] On Behalf Of<br>
| Christopher Allen<br>
| Sent: 17 October 2016 18:08<br>
| To: <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
| Subject: Improving GHC GC for latency-sensitive networked services<br>
|<br>
| It'd be unfortunate if more companies trying out Haskell came to the<br>
| same result:<br>
</span>| <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog" rel="noreferrer" target="_blank">https://na01.safelinks.protect<wbr>ion.outlook.com/?url=https%3A%<wbr>2F%2Fblog</a>.<br>
| <a href="http://pusher.com" rel="noreferrer" target="_blank">pusher.com</a>%2Flatency-working-s<wbr>et-ghc-gc-pick-two%2F%23commen<wbr>t-<br>
| 2866985345&data=01%7C01%7Csimo<wbr>npj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C04c1bc69<wbr>e00c47d382<br>
| 2908d3f6b028d0%7C72f988bf86f14<wbr>1af91ab2d7cd011db47%7C1&sdata=<wbr>dE1VP0u3kQ<br>
| L9R7CaGTAOGswRY6SyKH72c0xG%2FO<wbr>ggEK0%3D&reserved=0<br>
<span>| (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" target="_blank">ghc-devs@haskell.org</a><br>
</span>| <a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h" rel="noreferrer" target="_blank">https://na01.safelinks.protect<wbr>ion.outlook.com/?url=http%3A%<wbr>2F%2Fmail.h</a><br>
| <a href="http://askell.org" rel="noreferrer" target="_blank">askell.org</a>%2Fcgi-bin%2Fmailman<wbr>%2Flistinfo%2Fghc-<br>
| devs&data=01%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40<wbr>microsoft.com</a>%7C04c1bc69e00c47<wbr>d3822908d3<br>
| f6b028d0%7C72f988bf86f141af91a<wbr>b2d7cd011db47%7C1&sdata=<wbr>XwvaAPx%2BGqugD4<br>
| Kx%2FkXiYticgBCUMkboqH9QE315Eh<wbr>Q%3D&reserved=0<br>
<div class="m_-5764667909021617661HOEnZb"><div class="m_-5764667909021617661h5">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">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-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div></div>