Swift does away with pointers == pervasive ARC

[Nick Sabalausky via Digitalmars-d]

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:
>>>
>>> I don't think the user would enjoy the app "randomly" shutting down
>>> and starting up again on him. :-)
>>>
>>> One idea that occurs to me, though, is to split the app into a
>>> frontend that does not allocate during runtime, and a backend, which
>>> may. Design it in such a way that the backend can freely restart
>>> anytime without adversely affecting the frontend; then you can
>>> maintain an apparance of continuous execution across backend
>>> restarts.
>>>
>>> If the restart time can be reduced to within a single animation
>>> frame, for example, one could actually write a game engine that never
>>> deallocates, it just restarts itself when it runs out of memory and
>>> the frontend maintains the façade of continuous execution. This will
>>> trump GC, ARC, malloc, indeed, any memory allocation scheme beyond
>>> bump-a-pointer. :-P
>>>
>>
>> Sounds cool, but I would think in that case you may as well just stick
>> with region allocators. Same effect with less overhead and more
>> fine-tuning control. Or a global region allocator or something.
> [...]
>
> 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.

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