garbage collection in d

[Robert Jacques]

On Wed, 07 Apr 2010 15:40:27 -0300, Sean Kelly <sean at invisibleduck.org>  
wrote:
> 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.

Incremental / generational GCs also have problems with impure/non-OO  
languages like D. Finding the right GC flags is reasonable when there are  
only references to GC aware objects. Once you have to start putting the  
flags somewhere else, global locks tend to get involved.