Deterministic Memory Management With Standard Library Progress

[Guillaume Piolat via Digitalmars-d]

On Saturday, 4 March 2017 at 18:09:10 UTC, Anthony wrote:
> I've been having difficulty finding an up-to-date answer to 
> this question, so I figured I'd ask the forum: can 
> deterministic memory management be done in D, without losing 
> any main features?

First let's admit that C++ determinism is a strong point and that 
D fares a bit worse on this.

I'll give you the simplistic rules for deterministic destruction 
now (which is required for C++-style deterministic memory 
management). If you follow these rules your program destruction 
will be deterministic and you might even push into being 
exception-safe if you are so inclined. :)

- Use struct RAII wrappers and destructors to release resources. 
Typically structs with disabled postblit. However very often 
resources are classes objects because they feature virtual 
dispatch.

- In destructors, call .destroy on members that are class objects 
(reverse order of their creation if possible). Also on heap 
allocated struct but those are rare. The idea is that when the GC 
kicks in, unreachable objects on the heap should already have 
already been destroyed.

- Don't let the GC release resources, with the "GC-proof resource 
class idiom". I remember Andrei pushing for the GC not to call 
destructors, to no avail. So the GC is calling destructors and 
you should use it as a _warning that something is wrong_ and 
determinisim wasn't respected, not as a safety measure and a way 
to actually release resources (because it's wrong thread, wrong 
timing, unreliable).

- Like in C++, if your ownership is in the case where it's 
shared, you can introduce artificial owners (eg: arena pool owns 
arena pool items).

- The resources that are only memory need no owner and can be 
managed by the GC. (eg: strings, a ubyte[] array...)

When you have deterministic destruction, it's simple to offload 
work from GC to manual memory management. You don't loose ANY 
main feature.

The GC is an efficient way to call free(), and a global owner not 
a way to release resources.

The problem of GC efficiency itself is separate.