Can D's Garbage Collector be Very Fast?

[Vijay Nayar]

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?