On Saturday, 29 October 2022 at 04:46:21 UTC, Walter Bright wrote:
>On 10/28/2022 7:09 AM, ryuukk_ wrote:
...
i want D to grow, and it starts by acknowledging your shortcomings
a GC that is slower than GO's GC
And I acknowledge that. It will never be as fast as GO's GC. The reason is a technical one. GO is a GC-only language, which means it is optimized for the GC. All GO allocations are allocated on the GC heap...
>With such heavy GC allocation, a reasonable tradeoff is to insert "write gates" on every write through a pointer. This informs the GC that the allocation is "dirty" and so can be moved ...
...
The GO GC can also take advantage of always knowing exactly where all the GC pointers are, because there are only GC pointers. This enables a moving GC, which "compacts" fragmented memory.
From https://go.dev/blog/ismmkeynote "Getting to Go: The Journey of Go's garbage collector" I gather that the initial goal of general compacting was abandoned and that the purpose of the write barriers is to maintain tri-color invariants (white/black/gray) when the GC is active.
Perhaps I've misunderstood something?