www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts on a Future Garbage Collector

reply Jakob Jenkov <jakob jenkov.com> writes:
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.
Dec 03 2015
next sibling parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
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.
Dec 03 2015
parent Jakob Jenkov <jakob jenkov.com> writes:
Great to hear! Looking forward to learning more about how this 
all works!
Dec 03 2015
prev sibling next sibling parent reply Nerve <nervecenter7 gmail.com> writes:
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.
Dec 03 2015
next sibling parent Jakob Ovrum <jakobovrum gmail.com> writes:
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.
Dec 03 2015
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Dec 03 2015
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Dec 03 2015
prev sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
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?
Dec 03 2015
parent reply Jakob Jenkov <jakob jenkov.com> writes:
 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... !
Dec 11 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
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.
Dec 11 2015