Can D's Garbage Collector be Very Fast?

[Alex]

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?

D's GC is based on ancient ideas, it could be improved... it is 
not if but who. It takes work and no one is currently willing to 
put in the necessary work to make it happen.

D's GC could, for example, use a parallel thread which determines 
orphans and then release them. One does not have to stop the 
world if it knows a memory block is an orphan.

That is, if no pointers access a memory block then one knows 
absolutely it is orphaned(within proper program design). 
Reference counting is effectively tracking this.

The idea is to offload much of the work as possible to a parallel 
process that is provably safe and leave the work that requires 
stop the world to that process.

That is just one of many things that can be done. One of the 
problems is that D does not maintain contextual information that 
it could derive from the program structure itself to also reduce 
these problems. For example, not all memory is allocated as equal 
but treating it as such forces one in to the same algorithm to 
release it.

There has been some work on D's GC but the GC has not really been 
a focal point.

One can use custom memory management when needed and deal along 
with other patterns and it ideally reduces the GC dependence.

The worse thing about D's GC is it's implicit use in some 
operations such as AA's. It makes it much more difficult to 
reason about what really is going on in a program and where and 
forces one to use the GC even if it truly is not necessary.