Potential GSoC project - GC improvements

[Adam Wilson via Digitalmars-d]

thedeemon wrote:
> 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.
>

He did. And C# supports pinning so at some point all GC's are partially 
conservative. ;-)

> 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.
>

On this we are in complete agreement.

> 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.
>

Well, conclusively proving the cost of write-barriers would require 
profiling. But I think we should be able to optimize the use of 
write-barriers to reduce the impact.

Here is the thing, nobody wants to admit it, but we have lost the battle 
with C++, although to be honest, I don't think we ever had a prayer of 
winning it in the first place. They want C++ with the "warts" removed, 
for some personally distinct set of "warts", they're not really 
interested in D for itself.

Maybe ... why don't instead of trying to compete with everybody else, we 
do our own thing, and do it very well. As long as we're just another "me 
too" operation people will treat us like we are. Let's focus on being 
the best D language out there. And D needs a GC, so let's build the best 
damn garbage collector the natively-compiled world has every seen.

> 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.
>

Yea, this is true, although I think getting most of the way there is 
going to be very useful in it's own right. And it would open the 
possibility of experimenting with different algorithms and strategies. 
Right now we're pretty limited in the types of algorithms we can use, 
precision offers us more options and more experiments. Let's get the 
foundation in place, then we can go nuts.

>
>> 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.

Thank you. :)

-- 
// Adam Wilson
// quiet.dlang.dev