Hi D devs,
I read recently that D's garbage collector isn't the fastest, and
that you would like a faster one. I have some thoughts on that.
I have spent about 16 years with Java, and my experience with the
garbage collector typically falls into one of these two
categories:
Either the speed of the software didn't matter, and thus the
garbage collector didn't matter either.
Or, the speed of the software mattered, and the garbage collector
was never good enough, so you end up designing your software to
avoid the garbage collector (using arrays and object pools
instead of new'ing objects).
Rather than trying to come up with a "perfect" garbage collector
for D I would prefer if the memory system could become a first
class member of the language / libraries. Make it a component you
can access. Make it possible to:
- Hint to the memory system where to allocate an object, meaning
hinting if it is
- shortlived (like within a function), transaction scope (max
60 s life time),
- permanent singleton etc. Often you already know at
allocation time. Then the object
could be allocated directly at the right "generation" heap.
- Force the GC to run
- ... above, but with a maximum time allowed GC.
- Let developers be able to plug in their own garbage collection
algorithms.
- Allow multiple memory managers into which you can plug
different garbage collection strategies, and different heap
allocation / deallocation strategies (growing and shrinking the
heap of a memory manager).
My experience from Java is that one size never really fits all.
Open it up instead. Let the community "plug in" and I am sure D
will get a wealth of memory management strategies fast. Not just
1 garbage collector, but N garbage collectors.
