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

Reply via email to