Improving GHC GC for latency-sensitive networked services

[Harendra Kumar]

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.

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.

-harendra

On 18 October 2016 at 18:33, Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> |  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.
>
> 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.
>
> I'm not sure it'd help much here, since the data is long-lived and might
> migrate into the global heap anyway.
>
> 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.
>
> I believe the that the OCaml runtime now has such a GC.  It'd be lovely to
> have one for GHC.
>
> But I defer to Simon M
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Christopher Allen
> |  Sent: 17 October 2016 18:08
> |  To: ghc-devs at haskell.org
> |  Subject: Improving GHC GC for latency-sensitive networked services
> |
> |  It'd be unfortunate if more companies trying out Haskell came to the
> |  same result:
> |  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.
> |  pusher.com%2Flatency-working-set-ghc-gc-pick-two%2F%23comment-
> |  2866985345&data=01%7C01%7Csimonpj%40microsoft.com%7C04c1bc69e00c47d382
> |  2908d3f6b028d0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=dE1VP0u3kQ
> |  L9R7CaGTAOGswRY6SyKH72c0xG%2FOggEK0%3D&reserved=0
> |  (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 at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs&data=01%7C01%7Csimonpj%40microsoft.com%7C04c1bc69e00c47d3822908d3
> |  f6b028d0%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=XwvaAPx%2BGqugD4
> |  Kx%2FkXiYticgBCUMkboqH9QE315EhQ%3D&reserved=0
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161018/6037e436/attachment.html>