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