garbage collection in d

[Sean Kelly]

Daniel Oberhoff Wrote:
> 
> b) my reluctance to the dependency on a complex runtime as the one d i 
> is bringing at least due to its garbage collector
> 
> 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. is it reasonable to work without the collector, or are there 
> plans to upgrade to a concurrent one. also are there extensive 
> performance tests as how badly the collector interrupts real-time 
> processing?

It's still possible to build druntime with a custom GC.  You can even have a "GC" that simply calls malloc/free if you avoid coding that relies on implicit collection of discarded memory.  See gc_stub for an example.  As for better GC implementations, there are a bunch of options, but I don't know that we can go so far as an incremental collector ala Java.  That D can call C code causes problems there.