This is not really an article about "How the D garbage collector works", rather an article "How to avoid garbage in D". More tips and tricks are at: <a href="https://bitbucket.org/infognition/dstuff" rel="nofollow">https://bitbucket.org/infognition/dstuff</a><p>Here is the better explanation of the GC: <a href="https://dlang.org/spec/garbage.html" rel="nofollow">https://dlang.org/spec/garbage.html</a>, which is basically a very slow and conservative stop the world Mark & Sweep, which runs at every allocation. Basically a simple version of BoehmGC.<p>Due to the unfortunate C ABI, a fast copying collector is not really doable. One cannot track all the internal and external pointers. Well, one could, but has to pessimize the locals on every external pointer reference.
Too bad Dlang never reached mainstream. It's a perfectly suitable language for backend programming and system programming where golang is growing popular.
Has anyone here done any production-level stuff with D? I'm debating using it for my next project, but I want to see if it's industry-tested.
what are the advantages of running GC only when allocations are happening, instead of running concurrently?<p>Is the idea that you can explicitly control the behavior of GC by tuning your allocations? Is it burdensome for the programmer to constantly think about this while writing code?
If you are interested in current D memory management situation, you might want to look at this as well: <a href="https://dlang.org/phobos/std_experimental_allocator.html" rel="nofollow">https://dlang.org/phobos/std_experimental_allocator.html</a>