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