|  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-boun...@haskell.org] On Behalf Of
|  Christopher Allen
|  Sent: 17 October 2016 18:08
|  To: ghc-devs@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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to