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.
