Smart pointers instead of GC?

Araq rumpf_a at web.de
Tue Feb 4 05:03:23 PST 2014


>
> I've seen you say more than once that you can't bond with the 
> GC, and believe me I understand, if you search back through the 
> forums, you'll find one of the first things I did when I got 
> here was complain about the GC. But what you're saying is "I 
> can't bond with this horrible GC so we need to throw it out and 
> rebuild the compiler to support ARC." All I am saying is "I 
> can't bond with the horrible GC, so why don't we make a better 
> one, that doesn't ruin responsiveness, because I've seen it 
> done in other places and there is no technical reason D can't 
> do the same, or better."

There are lots of technical reasons why D's GC is just the way it 
is and why Java and C# can do better. They have been enumerated 
in this forum a lot of times, you simply chose to ignore them:

1. D doesn't restrict pointers, interior pointers abound 
especially thanks to the design of slices. Interior pointers are 
a problem for every high performance GC algorithm I'm aware of.
2. D's design doesn't easily allow for read or write barriers in 
general. You simply cannot make a GC behave without barriers.
3. Unions cause some (minor) problems.

In general the type system doesn't distinguish between GC'ed 
memory and manually managed memory at all.


> Now that I've started to read the GC Handbook I am starting to 
> suspect that using D, there might be a way to create a 
> completely pause-less GC. Don't hold me too it, I don't know 
> enough yet, but D has some unique capabilities that might just 
> make it possible.

That's just bullshit. The opposite is true: Of the big players D 
is easily the language that is most hostile to an efficient GC 
implementation.


More information about the Digitalmars-d mailing list