Re: [Haskell-cafe] concurrency vs. I/O in GHC

From: Claude Heiland-Allen
On 23/10/10 23:17, Donn Cave wrote:
Quoth Claude Heiland-Allen
, ... The conclusion I drew was that "unsafe" foreign functions block the current "capability" (OS thread) and any "threads" (Haskell forkIO etc) currently scheduled on that capability, but other capabilities and threads continue executing as normal.
... until GC time when all capabilities must be ready. (?)
That's quite interesting. Thanks very much to everyone who contributed to this. I think my understanding of the interactions between threads and foreign functions has deepened considerably. I may be able to accomplish what I want after all. I am somewhat surprised that all capabilities must be ready for GC; I thought with the parallel GC that wouldn't be necessary. But I don't know much about GC implementations so I try not to let their behavior surprise me too much. John

On 27/10/2010 05:00 PM, John Lato wrote:
I am somewhat surprised that all capabilities must be ready for GC; I thought with the parallel GC that wouldn't be necessary. But I don't know much about GC implementations so I try not to let their behavior surprise me too much.
GHC has a _parallel_ GC implementation, meaning that the GC event runs in parallel on several cores. But it does not (yet) have _concurrent_ GC, meaning that a GC event can happen at the same time as Haskell threads are running. (Basically, which Haskell code running, the references between objects could change while the GC engine is trying to analyse them, which would be Bad.) I understand that the developers are actively working on fixing this, since it can sometimes have a significant effect on the performance of multicore programs...

On Wed, Oct 27, 2010 at 23:09, Andrew Coppin
On 27/10/2010 05:00 PM, John Lato wrote:
I am somewhat surprised that all capabilities must be ready for GC; I thought with the parallel GC that wouldn't be necessary. But I don't know much about GC implementations so I try not to let their behavior surprise me too much.
GHC has a _parallel_ GC implementation, meaning that the GC event runs in parallel on several cores. But it does not (yet) have _concurrent_ GC, meaning that a GC event can happen at the same time as Haskell threads are running. (Basically, which Haskell code running, the references between objects could change while the GC engine is trying to analyse them, which would be Bad.) I understand that the developers are actively working on fixing this, since it can sometimes have a significant effect on the performance of multicore programs...
I thought that young generations could be GC'ed while other threads were running, while collecting the old generation required synchronizing all threads. This seems to be what is shown on http://hackage.haskell.org/trac/ghc/blog/new-gc-preview as well. Erik

On 28/10/2010 09:25 AM, Erik Hesselink wrote:
On Wed, Oct 27, 2010 at 23:09, Andrew Coppin
wrote: GHC has a _parallel_ GC implementation, meaning that the GC event runs in parallel on several cores. But it does not (yet) have _concurrent_ GC, meaning that a GC event can happen at the same time as Haskell threads are running. (Basically, which Haskell code running, the references between objects could change while the GC engine is trying to analyse them, which would be Bad.) I understand that the developers are actively working on fixing this, since it can sometimes have a significant effect on the performance of multicore programs... I thought that young generations could be GC'ed while other threads were running, while collecting the old generation required synchronizing all threads. This seems to be what is shown on http://hackage.haskell.org/trac/ghc/blog/new-gc-preview as well.
"I expect it to land in GHC HEAD in a few months time, and it should be in the autumn 2011 major release of GHC." In other words, this isn't how GHC works now, it's how some future version will work.

On Thu, Oct 28, 2010 at 19:06, Andrew Coppin
On 28/10/2010 09:25 AM, Erik Hesselink wrote:
On Wed, Oct 27, 2010 at 23:09, Andrew Coppin
wrote: GHC has a _parallel_ GC implementation, meaning that the GC event runs in parallel on several cores. But it does not (yet) have _concurrent_ GC, meaning that a GC event can happen at the same time as Haskell threads are running. (Basically, which Haskell code running, the references between objects could change while the GC engine is trying to analyse them, which would be Bad.) I understand that the developers are actively working on fixing this, since it can sometimes have a significant effect on the performance of multicore programs...
I thought that young generations could be GC'ed while other threads were running, while collecting the old generation required synchronizing all threads. This seems to be what is shown on http://hackage.haskell.org/trac/ghc/blog/new-gc-preview as well.
"I expect it to land in GHC HEAD in a few months time, and it should be in the autumn 2011 major release of GHC."
In other words, this isn't how GHC works now, it's how some future version will work.
Ah, sorry, I missed that. Erik
participants (3)
-
Andrew Coppin
-
Erik Hesselink
-
John Lato