On Thursday, 21 December 2017 at 22:11:26 UTC, Thomas Mader wrote:
D compiler also doesn't insert that bookkeeping code, so
running code is fast as C but GC is slow and sloppy.
But for D it's planned to rewrite the GC to become something
like the Go GC right?
The last attempt to do this was afaik a Google Summer of code
project.
No, not like in Go. A few years ago there was a project
implementing concurrent GC by forking the process and scanning
the heap snapshot in parallel to the main process. It kinda
worked but it's not portable, it won't work on Windows, so don't
expect it to land into main D distribution and become an official
GC.
There were other projects to improve current GC, make it more
precise (but still not 100% precise) and optimize to some extent,
but they don't bring substantial speed improvements, since the
main scheme remains the same: no write barriers, scan whole heap
every time and hope false pointers won't cause too much leaks.
Making the GC more like in Go and JVM means adding write
barriers, it means making general code slower (we're not
fast-as-C anymore), it means losing easy C compatibility (hello
FFI!), it means forbidding many current language features like
unions and casts, it means changing the language to something
that's not D anymore.
So I think we can expect some minor improvements in GC, but
nothing radical.
