garbage collection in d

[bearophile]

Daniel Oberhoff:

Just few comments on your post, other people will give you more answers.

> recently I even read one of the books (learn to tango with d)

That book is about D V.1 language, that is feature frozen. Most of the efforts are now on D2 language, that adds and changes several things (like the const system), and it currently uses only an improved version of Phobos.


> a) in the chaos that the language still seems to be in in that there is 
> no sharp specification and a lot of things changing rapidly

D1 is frozen, and D2 has recently stopped its quick development, now it's mostly a work of refining few edges, removing many bugs and implementing few parts missing still but already designed (and improving Phobos, for example with data structures).


> b) worries me a little. I am working towards real time systems with 
> tight time and sometimes also tight memory constraints, and a 
> conservative stop-the-world collector seems a bit daunting in this 
> context.

I think D GC has not being tested in stressfull serious situations yet.
I am not expert on this, but I think the soft real time requirement are not the main problem of the D GC, it starts working when you allocate memory, and there are many ways to disable it or avoid it to work in inner loops.
It main problem is probably that it's not precise, so it can cause leaks.


>is it reasonable to work without the collector,<

There is a way to disable it, and you can even remove it, but then you can't touch several features of the language (associative arrays, array/string copying, growing and concat, you can't use several functions in Phobos because they use GC, and so on). The D language is built around the GC. But in many situations you can keep the GC and use your own manual memory allocation schemes, for example using memory from the C heap. So you can use arenas, memory stacks, free lists, placement new of classes and structs, manual delete, or scope(exit) delete, and so on and on. I have successfully used several of those things in small D programs.


>or are there plans to upgrade to a concurrent one.<

Surely sooner or later the D GC will be updated, because it's not advanced, but there are more urgent things to do now, so it may take some years.


> also are there extensive performance tests as how badly the collector interrupts real-time processing?<

Not even one, as far as I know. Some people have written few small games with D1.


> keep up the good work, maybe I can contribute sometime, till then I 
> will linger a little more. :)

You can start writing some benchmarks to test the things you care more about :-)

Bye,
bearophile