<div dir="ltr">The impression I got reading the article was that their GC was very much like our current one except that the marking part of the algorithm was run concurrently.<div><br></div><div>That is the only reason I shared the article. To me it seems one should be to mark variables/types with which style of memory management it should use. I suppose that is what allocators are becoming.</div><div>Perhaps someone will write a concurrent generational garbage collected allocator.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 19, 2015 at 10:36 AM, thedeemon via Digitalmars-d-announce <span dir="ltr"><<a href="mailto:digitalmars-d-announce@puremagic.com" target="_blank">digitalmars-d-announce@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The new GC in Go 1.5 seems interesting. What they say about is certainly interesting.<br>
</blockquote>
<br></span>
They went the way of classical GC-ed language where write barriers are used actively, allowing to make concurrent, incremental and (eventually, if not yet) generational GC. However it has a cost - pointer field updates are slower than in plain C/C++/D, and overall speed is close to Java. D tries to be like C and C++ where simple code is fast and straightforward, there are no write barriers and there will never be, without changing the language design. It means D's GC will always be dog slow - it has to stop the world and scan full heap every time. And that leads to different usage pattern where GC heap should remain small and GC allocation rate low.<br>
<br>
</blockquote></div><br></div>