On Sunday, 18 December 2011 at 23:19:08 UTC, Adam Wilson wrote:
It seems to that we are really dancing around the potential
solution. A pluggable GC interface that allowed the developer
to choose the right GC for the task, or no GC at all. Imagine
if all the developer had to do is set a compiler switch and the
compiler automatically linked in the correct GC for the job. D
could ship with a default GC then others could write different
GC's based on different paradigms or their own needs. It would
be a piece of work to get the interfaces right, but definitely
worth it in the long run.
This pretty much already describes the current situation.
This is the interface:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/memory.d#L19
You can install your own GC as a "proxy" (this is used for
sharing the heap with shared objects):
https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L33
Theoretically this would also give the developer the ability to
link in multiple collectors and switch between them during
program execution, provided the working set data was stored in
a common format; although I have never heard of a use case for
such a capability.
It would probably be more practical to allow one GC to be
configurable at runtime.
I think supporting a NoGC environment is a good idea in the
long run as their are cases to be made for manual memory
management, but it also shouldn't be our first goal. GC's are
were the value is.
I believe there have been several attempts to start a no-GC
runtime+stdlib (including one of mine), but they never got off
the ground.
