On Wed, 07 Apr 2010 15:40:27 -0300, Sean Kelly <[email protected]>
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.
