Swift does away with pointers == pervasive ARC

H. S. Teoh via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 17 16:04:42 PDT 2014


On Tue, Jun 17, 2014 at 05:30:46PM -0400, Nick Sabalausky via Digitalmars-d wrote:
> On 6/17/2014 5:13 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Tue, Jun 17, 2014 at 04:36:49PM -0400, Nick Sabalausky via Digitalmars-d wrote:
> >>On 6/17/2014 3:04 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> >Hmm, that's an idea. Instead of having a region allocator bound to a
> >particular function scope, have it at global level, and when it runs
> >out of memory, it will invoke a delegate that deallocates it, create
> >a new allocator, and reload all the objects back (presumably, the
> >latest saved copy of the objects is good enough to continue running
> >with).
> >
> 
> Actually, I was just referring to traditional usages of region
> allocators, but that's an idea too.
> 
> >OTOH, thinking about this more carefully, it's no difference in
> >essence from a compacting GC (bump the pointer until you run out of
> >memory, then move all live objects to the bottom of the heap (i.e.
> >restart the backend and reload all "live objects" back into memory)
> >and start over), so this isn't exactly treading on new territory.
> >
> 
> I think there is a notable difference between this and compacting GC
> though.  With this, you're trading off the inconvenience of paying
> careful attention to data persistence and fast reloading, for the
> benefit of eliminating the potentially-doubled memory requirements of
> a traditional compacting GC.

But this may wind up being worse than a traditional compacting GC,
because now you have to manually do essentially what the compacting GC
does for you -- decide (on slow-access persistent storage, no less!)
which objects are live and which are dead. So you end up reimplementing
your own GC. And when memory runs out, you have to load things back from
said slow-access storage, whereas a compacting GC would have the benefit
of copying only within the relatively-faster RAM.


> It's an interesting thought. Especially since the persistence stuff
> has other benefits too, like improved fault tolerance (well, as long
> as the persisted data doesn't get corrupted).

I suppose if your program already has persistence built in, then you
might as well take advantage of it by foregoing any kind of memory
management and just restart when memory runs out. I'm not sure if it's
actually any *better*, though. All of this rests on the assumption that
it's possible to (re)load all your live objects from persistent storage
within the space of a single animation frame, which may not even be
possible to begin with! :-)


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis


More information about the Digitalmars-d mailing list