Smart pointers instead of GC?
Adam Wilson
flyboynw at gmail.com
Mon Feb 3 21:23:50 PST 2014
On Mon, 03 Feb 2014 18:57:00 -0800, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> On 2/3/14, 5:36 PM, Adam Wilson wrote:
>> You still haven't dealt with the cyclic reference problem in ARC. There
>> is absolutely no way ARC can handle that without programmer input,
>> therefore, it is simply not possible to switch D to ARC without adding
>> some language support to deal with cyclic-refs. Ergo, it is simply not
>> possible to seamlessly switch D to ARC without creating all kinds of
>> havoc as people now how memory leaks where they didn't before. In order
>> to support ARC the D language will necessarily have to grow/change to
>> accommodate it. Apple devs constantly have trouble with cyclic-refs to
>> this day.
>
> The stock response: weak pointers. But I think the best solution is to
> allow some form of automatic reference counting backed up by the GC,
> which will lift cycles.
>
> Andrei
>
The immediate problem that I can see here is you're now paying for TWO GC
algorithms. There is no traditional GC without a Mark phase (unless it's a
copying collector, which will scare off the Embedded guys), and the mark
phase is actually typically the longer portion of the pause. If you have
ARC backed up by a GC you'll still have to mark+collect which means the GC
still has to track ARC memory and then when a collection is needed, mark
and collect. This means that you might reduce the total number of pauses,
but you won't eliminate them. That in turn makes it an invalid tool for
RT/Embedded purposes. And of course we still have the costs of ARC. Manu
still can't rely on pause-free (although ARC isn't either) memory
management, and the embedded guys still have to pay the costs in heap size
to support the GC.
Going the other way, GC is default with ARC support on the side, is not as
troublesome from an implementation standpoint because the GC does not have
to be taught about the ARC memory. This means that ARC memory is free of
being tracked by the GC and the GC has less overall memory to track which
makes collection cycles faster. However, I don't think that the
RT/Embedded guys will like this either, because it means you are still
paying for the GC at some point, and they'll never know for sure if a
library they are using is going to GC-allocate (and collect) when they
don't expect it.
The only way I can see to make the ARC crowd happy is to completely
replace the GC entirely, along with the attendant language changes (new
keywords, etc) that are probably along the lines of Rust. I strongly
believe that the reason we've never seen a GC backed ARC system is because
in practice it doesn't completely solve any of the problems with either
system but costs quite a bit more than either system on it's own.
--
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
More information about the Digitalmars-d
mailing list