Can D's Garbage Collector be Very Fast?

[user1234]

On Wednesday, 8 May 2019 at 10:27:43 UTC, Vijay Nayar wrote:
> This is a very interesting read that talks about Go's evolution 
> of their garbage collector.  They have benchmarks showing a 
> "stop the world" pause of between 5 and 10 milliseconds 
> consistently.
>
> https://blog.golang.org/ismmkeynote
>
>> So what about write barriers? The write barrier is on only 
>> during the GC. At other times the compiled code loads a global 
>> variable and looks at it. Since the GC was typically off the 
>> hardware correctly speculates to branch around the write 
>> barrier. When we are inside the GC that variable is different, 
>> and the write barrier is responsible for ensuring that no 
>> reachable objects get lost during the tri-color operations.
>
> There are obviously cases where even such a pause is not 
> permitted, but these are the cases where custom allocators will 
> likely be written in any language. Given that the write-barrier 
> is only on when the Garbage Collector is being run, could D 
> also do something similar to have a very fast garbage 
> collector, but also allow even that small performance penalty 
> of a write barrier during GC collections to be avoided entirely 
> while using @nogc?

I'm not sure if I understand your concept of "write barrier". 
During collection it's not just a write barrier, it's a complete 
world that's stopped and the only thing that can run is a of low 
level thread written in a C style and allocating in a C style. 
Everything else would crash the program or not would not work at 
all.