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

[IGotD-]

On Thursday, 15 December 2022 at 12:55:22 UTC, Ola Fosheim 
Grøstad wrote:
>
> Anyway, concurrent collectors that don't stop the world are not 
> as bad if you add hardware capabilities that prevents the 
> caches for being flushed and the data-bus from being saturated. 
> You could have a separate hardware-cache for book-keeping tasks 
> and just slowly scan memory in the background rather than the 
> hit-and-run approach.

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.

In order to get tracing GC to work you need to.

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.

6. All this requires that the D runtime must keep track on all 
threads, something that you otherwise don't need since the 
kernel/other base runtime do this for you.

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.

8. You need to have a functionality that suspends the execution, 
that is on all CPUs. In order to to that all the CPUs needs to be 
interrupted. This operation itself takes time as it needs to save 
the context, go through the interrupt service routine, probably 
do something in the scheduler, also needs to report back to the 
requesting CPU. The code in D seems to stop the threads one by 
one so this operation itself takes time, more if there are more 
threads running on other CPUs. After the GC is done with its 
operation, it's the same story again but resuming the threads. A 
"short GC pause" is really a relative term.

9. There is probably more that I don't know about that would 
surprise me, not in positive way I'm afraid.

I must give the D project the credit for having the stamina 
implementing such infrastructure in the standard library. I would 
have given up and looked elsewhere. Also, I'm surprised that the 
operating systems offer such particular interfaces for 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?

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?