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."
