Thank you for the clarification. I had read those papers, but I was under the impression that it was something already part of GHC 7.<div><br></div><div>Regards,</div><div><br>Dave<br><br><div class="gmail_quote">On Thu, Sep 29, 2011 at 8:45 PM, austin seipp <span dir="ltr">&lt;<a href="mailto:as@hacks.yi.org">as@hacks.yi.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Thu, Sep 29, 2011 at 3:14 PM, David Barbour &lt;<a href="mailto:dmbarbour@gmail.com">dmbarbour@gmail.com</a>&gt; wrote:<br>

&gt;<br>
&gt; minor collections of this nursery do not result in whole system pauses.<br>
<br>
</div>Yes, they do. GHC has a parallel garbage collector (so collection<br>
pauses the mutator threads, and collects garbage -in parallel- on<br>
multiple CPUs) but it in no way has a concurrent one. Every OS thread<br>
has its own young-gen heap space, and the old-generation heap space is<br>
shared amongst every CPU. But any young-gen GC will cause all mutator<br>
threads to pause no matter what the state of the others is.<br>
<br>
That said, Simon^2 has done research on this problem recently. They<br>
recently published a paper about &#39;local&#39; garbage collection for<br>
individual OS threads, where every thread has its own, private<br>
nursery, that may be collected independently of all other CPUs, which<br>
promotes objects into the global heap when necessary for access from<br>
other threads. The design is reminiscent of older work on the same<br>
topic (thread-local heaps,) but adds a bunch of tasty work they did.<br>
<br>
You can find this branch of GHC with &#39;local heaps&#39; here, in the<br>
local-gc branch of the git repository:<br>
<br>
<a href="https://github.com/ghc/ghc/tree/local-gc" target="_blank">https://github.com/ghc/ghc/tree/local-gc</a><br>
<br>
This new local collector branch is not, I repeat, not part of GHC and<br>
hasn&#39;t been merged. It&#39;s not certain if it ever will be, I think. The<br>
paper conclusion addresses the fact the scalability improvements as a<br>
result of this new collector are nowhere near as dramatic as they had<br>
hoped, and it&#39;s not certain the improvements they did get are worth<br>
the substantial complexity increase. It doesn&#39;t address the old-gen GC<br>
- any old-gen GCs still pause all mutator threads before continuing.<br>
They do note however that this local allocation strategy could be<br>
combined with a real concurrent/incremental GC for the old-generation,<br>
which would help control pause times more over the whole lifetime of<br>
an application.<br>
<br>
You can find all the juicy details in their paper &quot;Multicore garbage<br>
collection with thread local heaps&quot;, located near the top of Simon&#39;s<br>
webpage here:<br>
<br>
<a href="http://research.microsoft.com/en-us/people/simonpj/" target="_blank">http://research.microsoft.com/en-us/people/simonpj/</a><br>
<font color="#888888"><br>
--<br>
Regards,<br>
Austin<br>
</font></blockquote></div><br></div>