The D standard library is built on GC, is that a negative or positive?

[Ola Fosheim Grøstad]

On Saturday, 17 December 2022 at 18:44:21 UTC, IGotD- wrote:
> I see concurrent GC (or at least something that doesn't stop 
> other threads) as the only choice. The more I look into the D 
> garbage collector the more surprised I become.

I wouldn't say it is is the only choice. If D was willing to make 
a bold move towards modelling software as short lived 
actors/tasks then you could use arenas that typically don't 
collect, but is wiped out when the task is done (collection only 
happens if you run out of memory).

Right now I am personally more interested in Carbon that will be 
100% GC free. I like that they take a stance on memory management 
overhead. There are also interesting things going on in the 
research field with separation logic and similar formalizations, 
still probably 20 years until it will be generally useful, but 
things are moving IMO. There is also some interest in memory 
pools/arenas in the C++ community I think, and there seems to be 
an interest in Apple for integrating C++ and Swift, so maybe 
pairing one managed and one unmanaged language is the way 
forward, short term. So overall, the global picture is nuanced.

> 1. Scan the stack from the stack pointer and upwards.
> 2. Scan all the registers, making the algorithm non portable.
> 3. Scan all the globally allocated memory
> 4. Scan all the thread local storage. This usually live on the 
> stack for the libraries that are loaded at startup. This 
> information must be read out before or after the thread starts.
> 5. The threads that were interrupted, the context must be read 
> out including the position of the stack pointer.

Application specific collectors don't have to do all this work as 
they will only collect at specific points where the state is 
known and where the number of live objects are minimal. This is 
something one should be able to use verification technologies 
for, basically proving that there are no stray references hanging 
around when you start collecting. Rust is only the beginning I 
think.

> 7. You need metadata for the tracing graph. D uses typeinfo in 
> order to reduce the scanning of objects, this is nice but at 
> the same increases the complexity.

You could probably generate a hardcoded "optimal" scanner 
statically at linktime after LTO, but that only makes it somewhat 
faster, and not really better.

> making this possible. It's not completely straight forward and 
> suspending all threads require quite different approaches on 
> each system. What if they didn't?

Suspending all threads, for whatever reason, is a terrible idea. 
Just think about Amdahl's law:

https://en.wikipedia.org/wiki/Amdahl%27s_law#/media/File:AmdahlsLaw.svg

> So the question if GC is built into the standard library is 
> positive or negative, then my answer is that in the case of the 
> D it certainly increase the complexity quite a lot. What if 
> there was a simpler path?

ARC.