Future of memory management in D

[Ola Fosheim Grøstad]

On Wednesday, 17 November 2021 at 16:27:10 UTC, SealabJaster 
wrote:
> I wonder if we could make this a bit less painful if we had a 
> thread-local GC by default, and another global GC purely for 
> `shared` memory.

GC should not be thread-local. It should be local to the 
computation. The computation has to be able to move between 
threads to get proper balanced load and high throughput.

The *big* advantage here is that for most computations you 
probably don't have to collect at all. You just release the heap 
when the computation is completed. This can be very fast if you 
separate objects with destructors from those without.

> So `new Class()` might only stop the current thread, while `new 
> shared Class()` might stop the world.

No. ```new Class()``` will:

1. try to collect its own heap if possible

2. try to collect the heaps of inactive pending computations if 
possible

3. try to grab more memory form the OS if possible

4. trigger a collection of the shared heap

5. put the computation to sleep and wait for other computations 
to release memory

That does not help much for those that want low latency and 
predictable performance. You also don't want to freeze 
computations that do not use ```shared```at all, and freezing the 
world on ```new shared``` is not acceptable for low latency 
computations anyway.

You need to use RC on shared to get decent performance.