<story><title>Why is D&apos;s garbage collection slower than Go&apos;s?</title><url>https://forum.dlang.org/post/tjib6h$2pp6$1@digitalmars.com</url></story><parent_chain></parent_chain><comment><author>hayley-patton</author><text>The Go collector isn&amp;#x27;t generational or moving, and the write barrier AIUI is only used for getting it to run concurrently. The barrier records interesting writes when the collector is running, to avoid &amp;quot;losing&amp;quot; objects whose liveness changed while the collector was running.&lt;p&gt;Barriers are pretty cheap; [0] claims a 0.9% time overhead for a card-marking barrier common in generational collection and 1.6% for an object-logging barrier which is also useful for concurrent collection. Apparently they&amp;#x27;re cheaper nowadays, but the results aren&amp;#x27;t published yet [1]. That&amp;#x27;s not to say that the barriers are free, but it seems feasible that collector optimisations could still cover that ground.&lt;p&gt;It can help throughput, still, by running the collector concurrently. I&amp;#x27;ve felt that while working on a new parallel (but not yet concurrent) collector for SBCL; the program parallelises well, but a serial collector hurts worse than it should by stopping the program.&lt;p&gt;[0] &amp;quot;Barriers reconsidered, friendlier still!&amp;quot; &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;users.cecs.anu.edu.au&amp;#x2F;~steveb&amp;#x2F;pubs&amp;#x2F;papers&amp;#x2F;barrier-ismm-2012.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;users.cecs.anu.edu.au&amp;#x2F;~steveb&amp;#x2F;pubs&amp;#x2F;papers&amp;#x2F;barrier-is...&lt;/a&gt;
[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;twitter.com&amp;#x2F;stevemblackburn&amp;#x2F;status&amp;#x2F;1494240906006110209&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;twitter.com&amp;#x2F;stevemblackburn&amp;#x2F;status&amp;#x2F;14942409060061102...&lt;/a&gt;</text></comment>
<story><title>Why is D&apos;s garbage collection slower than Go&apos;s?</title><url>https://forum.dlang.org/post/tjib6h$2pp6$1@digitalmars.com</url></story><parent_chain></parent_chain><comment><author>masklinn</author><text>&amp;gt; And since there are all kinds of pointers in D, one no longer can use a moving GC allocator, because it cannot know exactly where 100% of the GC pointers are.&lt;p&gt;Go&amp;#x27;s GC is non-moving and it can&amp;#x27;t safely be made moving in the current state[0].&lt;p&gt;It also used to be partially conservative until 1.3[1][2][3]: the heap was precise, but the stack was conservative.&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;golang&amp;#x2F;go&amp;#x2F;issues&amp;#x2F;46787&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;golang&amp;#x2F;go&amp;#x2F;issues&amp;#x2F;46787&lt;/a&gt;&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;go.dev&amp;#x2F;doc&amp;#x2F;go1.3#garbage_collector&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;go.dev&amp;#x2F;doc&amp;#x2F;go1.3#garbage_collector&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.google.com&amp;#x2F;document&amp;#x2F;d&amp;#x2F;1lyPIbmsYbXnpNj57a261hgOYVpNRcgydurVQIyZOz_o&amp;#x2F;pub&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.google.com&amp;#x2F;document&amp;#x2F;d&amp;#x2F;1lyPIbmsYbXnpNj57a261hgOY...&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.google.com&amp;#x2F;document&amp;#x2F;d&amp;#x2F;13v_u3UrN2pgUtPnH4y-qfmlXwEEryikFu0SQiwk35SA&amp;#x2F;pub&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.google.com&amp;#x2F;document&amp;#x2F;d&amp;#x2F;13v_u3UrN2pgUtPnH4y-qfmlX...&lt;/a&gt;</text></comment>