Why is D's GC slower than GO's?

[Adam D Ruppe]

On Saturday, 29 October 2022 at 10:35:21 UTC, Walter Bright wrote:
> I've pointed out the problems with two hierarchies of pointers 
> many times.

D already has several kinds of pointers. T*, const(T)*, 
shared(T)*. I don't see how unmanaged(T*) is any different.

In fact, I sketched up some thoughts i might put in the blog 
monday but the short of it is you could:

* -ptrcheck=[none|barrier] argument to the compiler, similar to 
how -checkaction and -boundscheck can be modified.

* all pointer writes assumed to be barriered except ones marked 
raw/unmanaged/whatever, which is a qualifier similar to const and 
shared

* the raw pointer would essentially be struct raw(T) { T it; 
alias it this; void opAssign(T rhs) { barrier(); it = rhs; } }

* possible optimizations would be eliding the barrier in cases 
like `a = a[1 .. $]` because you know - thanks to the bounds 
check - that this refers to the same memory block anyway and is 
thus irrelevant to the GC wrt marking. I guess it can be trouble 
if it wants to move tings in the middle of the slice operation 
though.


I'm not convinced this is impossible.

(btw im also not convinced it is necessary, i think D's gc is 
good enough as it is.)