On Monday, 14 March 2016 at 01:38:50 UTC, Adam Wilson wrote:
Lastly, Rainer seemed to think a precise GC could be done, and he then went and did it ... so "can't reasonably have a precise collector" is a factually incorrect assertion.
IIRC, Rainer called it "mostly precise", and for a good reason. If we're ok with calling a partially conservative GC a precise one, then go on. ;) As I understand Rainer's GC works in VisualD now and it did solve the problem of leaks he had with the default GC, so there is certainly benefit in pursuing preciseness, even non-100% one.
I think continuing Rainer's work toward "even more precise" GC, and adding important optimizations like allocations without a global lock and parallel scanning would be a great project, and a realistic one.
As for moving and generational GC, I have big doubts one can do it without breaking 90% of old code written in D (passing pointers to C libs) and turning the language into yet another C# with write barriers everywhere. Now D competes in speed with C++, with your proposed changes it will only try to compete with Java and C#, i.e. battle with C++ will be lost. On the other hand I might be overestimating write-barriers costs, please feel free to prove me wrong.
Fun part: if you make a moving GC and try to automate pinning and let the compiler do it instead of requiring programmers to rewrite most of their D code, you'll probably end up with a "partially moving GC" where half of the heap is pinned, some objects are moving here and there, and GC rarely releases memory back to OS because of those pinned objects.
My GC lingo may be rusty, and I will admit to using superlatives incorrectly myself, but based on the existing evidence my assertions are hardly "almost all wrong".
They did look so, sorry. Additional explanations helped.
