Future of memory management in D

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Thu Nov 18 13:56:42 UTC 2021


On Thursday, 18 November 2021 at 13:38:58 UTC, Atila Neves wrote:
> On Wednesday, 17 November 2021 at 21:59:51 UTC, Ola Fosheim 
> Grøstad wrote:
>> On Wednesday, 17 November 2021 at 21:46:45 UTC, Atila Neves 
>> wrote:
>>> The GC isn't going anywhere. It's the easiest way to write 
>>> memory-safe code other than leaking everything.
>>
>> What is the plan for destructors?
>>
>> Objects with destructors should not be allocated on the 
>> GC-heap. Will this become a type error that is caught at 
>> compile time?
>
> No plans right now. Refresh my memory: what are the main issues?

Off the top of my head:

1. The main issue is that beyond the trivial examples destruction 
order matters and you need to keep objects alive to get the 
correct cleanup of resources. Think database/transaction, 
GPU/texture, etc. So if you assume RAII for aggregates, then 
aggregates written for those won't work with GC. Though you could 
support both by adding finalizer handlers, then you could deny GC 
allocation of objects with destructor and no finalizer handler. 
(just one possibility)

2. Performance of GC collection will be faster if you have no 
destructors. Especially if you move to local GC heap (per actor). 
Then you can just release the whole heap and do no scanning when 
the actor is done. If the average actor's lifespan is short and 
you have plenty of memory, the GC overhead will drop from "O(N)" 
to "O(1)" (average).

Might be other issues.



More information about the Digitalmars-d mailing list