Smart pointers instead of GC?

Manu turkeyman at gmail.com
Mon Feb 3 22:12:18 PST 2014


On 4 February 2014 15:23, Adam Wilson <flyboynw at gmail.com> wrote:

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

So, the way I see this working in general, is that because in the majority
case, ARC would release memory immediately freeing up memory regularly, an
alloc that would have usually triggered a collect will happen far, far less
often.
Practically, this means that the mark phase, which you say is the longest
phase, would be performed far less often.

For me and my kind, I think the typical approach would be to turn off the
backing GC, and rely on marking weak references correctly.
This satisfies my requirements, and I also lose nothing in terms of
facilities in Phobos or other libraries (assuming that those libraries have
also marked weak references correctly, which I expect phobos would
absolutely be required to do).

This serves both worlds nicely, I retain access to libraries since they use
the same allocator, the GC remains (and is run less often) for those that
want care-free memory management, and for RT/embedded users, they can
*practically* disable the GC, and take responsibility for weak references
themselves, which I'm happy to do.


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

It also means that phobos and other libraries will use the GC because it's
the default. Correct, I don't see this as a valid solution. In fact, I
don't see it as a solution at all.
Where would implicit allocations like strings, concatenations, closures be
allocated?
I might as well just use RefCounted, I don't see this offering anything
much more than that.

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.


Really? [refer to my first paragraph in the reply]
It seems to me like ARC in front of a GC would result in the GC running far
less collect cycles. And the ARC opposition would be absolved of having to
tediously mark weak references. Also, the GC opposition can turn the GC
off, and everything will still work (assuming they take care of their
cycles).
I don't really see the disadvantage here, except that the
only-GC-at-all-costs-I-won't-even-consider-ARC crowd would gain a
ref-count, but they would also gain the advantage where the GC would run
less collect cycles. That would probably balance out.

I'm certainly it would be better than what we have, and in theory, everyone
would be satisfied.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140204/a8c7719f/attachment-0001.html>


More information about the Digitalmars-d mailing list