garbage collection in d

[Jacob Carlborg]

On 4/7/10 20:40, Sean Kelly 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.

Maybe something like the AutoZone collector on Mac OS X: 
http://www.opensource.apple.com/source/autozone/autozone-77.1/README.html?f=text

"AutoZone is a scanning, conservative, generational, multi-threaded 
garbage collector."

"... the implementation is language agnostic".

"The AutoZone collector is implemented in C++ and is designed to work in 
a runtime where some or most of the application's memory may be managed 
by mechanisms other than the collector."