Potential GSoC project - GC improvements

[thedeemon via Digitalmars-d]

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.