
Inside D's GC - arunc
http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html
======
dawg
The D language is currently heading towards deterministic and safe memory
management, making it possible to avoid the GC overall, hence further work on
GC improvements was deprioritized. [http://dlang.org/blog/2017/06/16/life-in-
the-fast-lane/](http://dlang.org/blog/2017/06/16/life-in-the-fast-lane/)

The problems are known and indeed a full rewrite on this ancient GC would be
in order. Since D 2.072.0 it's possible to link and use different GCs, so a
faster one could be written as an external library which would be a very
welcome effort. [https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-
ad...](https://dlang.org/changelog/2.072.0.html#gc-runtimeswitch-added)

I'd be interested in experimenting with a Connectivity-Based GC
([https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf](https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf)),
leveraging type information to do partial collections. Write barriers come
with a performance penalty (~3-5%) that we don't want to impose on people
using deterministic memory management, but most GCs capable of performing
partial collections, e.g. generational GCs, do require write barriers,
Connectivity-Based GCs do not.

For the time being the pragmatic advise is to replace major sources of GC
allocations with deterministic memory management when the GC heap grows too
big (~1GB) and performance becomes a problem.

So far this hasn't prevented various people from writing extremely fast D
programs.

~~~
amelius
> The D language is currently heading towards deterministic and safe memory
> management, making it possible to avoid the GC overall

Is this really true?

~~~
WalterBright
Yes. I gave a presentation on this at DConf 2017.

[http://dconf.org/2017/talks/bright.html](http://dconf.org/2017/talks/bright.html)

~~~
amelius
But is it really possible to completely avoid the GC? I'm thinking of memory
blocks with cyclic references, and stuff like that.

------
Dzugaru
D is the most promising "one to rule them all" languages for me, given it's
expressive power, speed, compilation speed and support for multiple paradigms.
That said, D severely lacks manpower in its development.

I'd like to port author's effort to Windows, but I don't have OS-level
programming experience, so I don't even know what are the differences and how
they affect GC algorithms described.

------
pcwalton
Immix is a copying collector. It's late and I may be misreading, but glancing
at the code I don't see any precise object layout info for the heap in D's GC.
That is, D seems conservative for both stack and heap. How can you make Immix
work with this kind of conservative GC?

~~~
chrisseaton
Presumably adding precise stack maps and object maps would be the first step
of adding IMMIX. I mean it's the compiler that chooses where to place things
in the heap and the stack, so it already knows where they are.

~~~
readittwice
Since, I don't know D, I am curious whether D-code is written in such a way
that objects are assumed to be non-moving, especially when interfacing with C.

~~~
biotronic
The spec says the GC may move, though the current GC doesn't do that:

[https://dlang.org/spec/garbage.html#obj_pinning_and_gc](https://dlang.org/spec/garbage.html#obj_pinning_and_gc)

There's also been some work on a precise GC for D:

[https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlan...](https://forum.dlang.org/post/hdwwkzqswwtffjehenjt@forum.dlang.org)

------
papaf
Good luck with this. I find GC programming really hard as any small mistake
snowballs and becomes super hard to find during debugging.

Some of the mistakes seen by the author could just be the original programmers
being tired of painful debugging.

~~~
gwbas1c
What are you talking about? GC programming is usually the easiest to avoid
small mistakes.

Circular references? GC will collect them! (Reference counting does not handle
circular references.)

Usually the two mistakes with GC are forgetting to empty collections, (which
is also a problem with manual memory management,) and relying on finalizers to
clean up resources.

GC will not "read your mind" and magically close your open sockets, release
your file handles, and dereference your static references. It just frees you
from the tedium of releasing transient memory, like strings; and it frees you
from tracking lifetimes of memory when you don't need to.

In my experience, the programmers who have trouble with GC are the ones who
don't understand the difference between memory management and resource
management.

~~~
distances
They meant implementing the GC itself.

------
jacquesm
If D manages to side-step the GC completely then Rust suddenly has a
formidable competitor.

~~~
kibwen
Rust already had a much more formidable competitor in C++. :P It would make no
sense for Rust to bother competing directly with D, and likewise it would make
no sense for D to bother competing directly with Rust. If you want market
share, you have to pile on the leader rather than waste your energy
cannibalizing the minnows.

~~~
bachmeier
More important than competing is to make it easy to call libraries written in
one language from the other. extern(Rust) would be a nice addition to D.

~~~
he_the_great
Rust just needs to add extern(C++) like D has and then they can communicate.

~~~
destructionator
or extern(C)...?

