Thoughts on a Future Garbage Collector

[Jakob Jenkov via Digitalmars-d]

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.