Thoughts on a Future Garbage Collector

Jakob Ovrum via Digitalmars-d digitalmars-d at puremagic.com
Thu Dec 3 10:49:12 PST 2015


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.


More information about the Digitalmars-d mailing list