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.

On Thursday, 3 December 2015 at 18:36:22 UTC, Jakob Jenkov wrote:
> - 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.

D provides full control over where to allocate memory. Most D programs use a mix of stack, GC heap and C heap (malloc) memory. std.allocator (currently std.experimental.allocator) provides a rich interface for composable allocators and also provides many useful compositions out of the box.

>
> - Force the GC to run

This is already supported.

> - ... above, but with a maximum time allowed GC.

There is no incremental tracing GC for D at this time. I don't know of anything in development, either.

> - Let developers be able to plug in their own garbage collection algorithms.

This is already supported.

> - 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).

The allocator interface supports growing and shrinking.

> 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.

I think you're completely right, and we've been heading in that direction for a few years now (basically since D2, maybe even longer). There has been a lot of recent improvements to the tracing GC with some more improvements in the pipeline, but generally the tracing GC is not as important in D because it's really easy to use alternative strategies, often without compromising memory safety.

Another strategy that is currently receiving attention in the D community is memory safe reference counting.

On Thursday, 3 December 2015 at 18:36:22 UTC, Jakob Jenkov wrote:
> 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.

One approach might be to allow for memory management with better primitives that simplify the design of manually managed software.

I've been greatly enjoying Jonathan Blow's video blogs on the design of his own language, Jai. It's targeted at game programmers, and as such he's gone to great pains to ensure language primitives remove the friction from manually allocating and deallocating memory, while still providing the full power of such a system.

I wonder what Walter and Andrei think of potentially overhauling those elements in D. Right now all of the manual memory management is basically ripped from C and C++ with no changes, and no insights into how to improve such a system. But I do see why they went that route. Type safety is a top concern.

On Thursday, 3 December 2015 at 19:03:35 UTC, Nerve wrote:
> I wonder what Walter and Andrei think of potentially overhauling those elements in D. Right now all of the manual memory management is basically ripped from C and C++ with no changes, and no insights into how to improve such a system. But I do see why they went that route. Type safety is a top concern.

We have templates, these can be done in the library. See e.g. std.experimental.allocator.make.

Great to hear! Looking forward to learning more about how this all works!

On 12/03/2015 10:36 AM, Jakob Jenkov wrote:

> 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).

Although that has been implied so many times on these forums, I like your description.

Ali

On Thursday, 3 December 2015 at 19:03:35 UTC, Nerve wrote:
> changes, and no insights into how to improve such a system. But I do see why they went that route. Type safety is a top concern.

Did you mean memory safety? Neither C++ or D offer much help if you want strong nominal typing. Which is a pity, because it makes my typesafe code look like a mess.

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?

> 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?


I don't know - what does it do? I am pretty new to D... !

On 12/12/15 7:51 AM, Jakob Jenkov wrote:
>> 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?
>
>
> I don't know - what does it do? I am pretty new to D... !

It is not DIP ready, but basically would allow at runtime annotating some memory with behavior e.g. allocation strategy, when to deallocate ext.

It would also almost force 'ownership' on it.