
The D Garbage Collector - sconxu
https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
======
rurban
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:
[https://bitbucket.org/infognition/dstuff](https://bitbucket.org/infognition/dstuff)

Here is the better explanation of the GC:
[https://dlang.org/spec/garbage.html](https://dlang.org/spec/garbage.html),
which is basically a very slow and conservative stop the world Mark & Sweep,
which runs at every allocation. Basically a simple version of BoehmGC.

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.

~~~
p0nce
A fast copying collector for D would require write barriers: using memory
barriers everytime a pointer is written. This has a runtime cost.

> which runs at every allocation.

The article explains in great depth that this is not the case.

~~~
pcwalton
> A fast copying collector would require write barriers: using atomics
> everytime a pointer is written.

No, for two reasons:

1\. Write barriers are not necessary if an object is in a nursery, which is
true for most objects per the generational hypothesis. This is trivial to
check based on the pointer value.

2\. You can have thread local remembered sets.

~~~
p0nce
I read this in
[http://www.infognition.com/blog/2014/the_real_problem_with_g...](http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html)
better ask the author of the article if you have a way for a better D GC.

> To make fast GC it needs to be generational, but generational GC means write
> barriers: you can't just freely mutate memory, every pointer mutation must
> be accompanied by additional bookkeeping.

I guess that in the context of D generations are not possible or practical. If
you have any idea why it should be possible, you may write a DIP.

~~~
WalterBright
It's possible to do generational collection in D. I've written one before and
was careful to design the semantics of D to allow for it. It just needs
someone to spend the time to implement it (the core language doesn't need to
change).

I'm skeptical, however, if it will offer a real improvement.

------
zyngaro
Too bad Dlang never reached mainstream. It's a perfectly​ suitable language
for backend programming and system programming where golang is growing
popular.

~~~
dpc_pw
If D had in-language-integrated Fibers like Go does it would be just better in
every aspect. Native-fast code, fast compile, powerful generic and meta-
programming. It was trying to be better C/C++ but should have instead push
where Go is going: highly productive and fast. I think Rust is much better C
replacement - much higher overhead and mental cost, for software that can't
compromise on performance, reliability and safety.

~~~
WalterBright
I'm not sure that language integrated ones would be better. As D's abstraction
abilities have improved, we've been moving features from the core language to
the library.

~~~
dpc_pw
The only thing that I find great about Go is the fact that you can write,
normal, imperative, blocking-io-like code dealing with about anything
(network, file, any io) and get a service that can handle 10k concurrent
connections without thinking much about it. If D could do the same, no matter
if through language support, or a library it would be really awesome. Note: it
seems to me, currently D's fibers require manual `yield`. The entire point is
not to have to do it.

------
tombert
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.

~~~
swah
Most folks will say that either C++ has improved or use Rust. (D was a really
lovely experience a few years ago, though..)

~~~
p0nce
Most folks haven't tried D.

~~~
x0x0
Since you use it in prod / sell products written in it, could you (briefly)
share why you like it and the advantages you see in it? Thank you!

~~~
p0nce
Went from Delphi to Ocaml to lots of C++ to D. Basically I'm happier with the
products I wrote in D so I keep using it. It's an almost schizophrenic
language that always says "yes" when you ask if something is possible. The
community regularly "discovers" new idioms within the language.

Learning D for real is as involved as any other language, but what people
remark first is the low mental overhead and how absurdly practical it is.

Advantages I see would be: fast to edit, compile, and run. Non-controversial
syntax, focus on power, and the fact you kind of already know it.

~~~
int_19h
How good is the tooling? IDE support, code completion and debugging
especially.

~~~
Ace17
There are 3 major compiler implementations (dmd, gdc, ldc).

I mostly work with gdc from GNU/Linux, and basically, everything that works
with g++ works with gdc. More precisely, I use, on a daily basis: \- vim +
ctags (editor + symbol lookup) \- gdb (debugger) \- gcov (code coverage) \-
valgrind (mostly callgrind (call-graph) and massif (memory profiler)) \-
oprofile (cpu profiler)

Unfortunately there's no ccache equivalent yet, and I'm missing it.

For the Windows people, there's VisualD, which basically is the integration in
Visual Studio. At this point, you have an IDE and a debugger (I don't know
about code completion).

There's also a build-tool (with package-managing abilities), called "dub" ;
that handles fetching and building external dependencies (in the vein of npm).

~~~
int_19h
I'll need to check out VisualD.

Someone should do a Language Server Protocol
([http://langserver.org/](http://langserver.org/)) implementation for D -
that's clearly the way forward. Right now this will give you VSCode, Eclipse
and NeoVim, with regular Vim and Emacs on the way.

VSCode also has something similar for debugging
([https://code.visualstudio.com/docs/extensionAPI/api-
debuggin...](https://code.visualstudio.com/docs/extensionAPI/api-debugging)),
but it hasn't been standardized in a similar fashion (yet?).

~~~
p0nce
I use the debugger in VisualD on Windows and LDC on macOS. I guess you can
also use the one in Visual Studio Code. There is ongoing work with the LSP
actually, since the VSC integration uses something similar already.

~~~
int_19h
BTW, I tried VisualD, and it seems that its code completion support is
rudimentary. I could get it to complete functions _sometimes_ , and I couldn't
get it to complete members at all. Obviously, no refactoring either. It's
unfortunate, but that would be a blocker for me.

------
dominotw
what are the advantages of running GC only when allocations are happening,
instead of running concurrently?

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?

~~~
p0nce
> what are the advantages of running GC only when allocations are happening,
> instead of running concurrently?

That way you don't need a dedicated thread for the GC (current one is
hijecked).

> Is it burdensome for the programmer to constantly think about this while
> writing code?

Not really. I sell real-time software in D, you don't constantly think about
this when writing code. It's no more burden that avoiding allocations in real-
time software in C++.

~~~
adrianratnapala
But avoiding allocations in real-time C++ is a burden to some (increasingly
common) kinds of programmers.

The kids today are so indoctrinated in modern C++ that they don't stop to
think that `vector<>::push_back()` potentially allocates behind the scenes.

Writing real-time code requires a certain mentality that is at odds with
modern frameworks. I expect nice languages like D have similar cultural
issues.

~~~
p0nce
If you need a feel of what the community values (apart from rants), have a
look at the forums. [https://forum.dlang.org/](https://forum.dlang.org/)

D is backed by companies like Sociomantic and Weka.io that operates in high-
performance domains.

------
nialv7
If you are interested in current D memory management situation, you might want
to look at this as well:
[https://dlang.org/phobos/std_experimental_allocator.html](https://dlang.org/phobos/std_experimental_allocator.html)

