On 04/12/15 7:36 AM, Jakob Jenkov wrote:
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.
A little something I've been working on for making into a DIP: http://wiki.dlang.org/User:Alphaglosined/ManagedMemory Would it be to your liking?
