Explict Memory Managment
David Semeria
david at lmframework.com
Fri May 22 08:21:00 PDT 2009
Hi, first post, so please excuse any clumsiness.
As a developer of large scale in-browser web apps, I frequently face
memory management issues. These issues apply to both managing DOM
elements (which I appreciate is beyond the scope of ECMA) but also to
managing objects within the script context.
I also appreciate that memory management is implementation specific, but
I would also assume that any direct calls to the memory management
system would be part of the language syntax.
I believe the problems I am faced with are common to many other
developers, and, as web applications become more complex, they will
become increasingly prevalent.
Basically I would like to suggest three methods: obj.kill()
obj.swapOut() obj.swapIn()
These are pretty self-explanatory.
obj.kill() would erase the object and immediately release any memory
used by the object
obj.swapOut() would swap out and release any memory used by the obj
obj.swapIn() would bring the object back.
References to swapped-out objects would automatically trigger their
swapIn() method.
The necessity for these last two methods arises when the application has
downloaded a large quantity of information which it does not currently
need – but may well do in the future. The built-in garbage collector has
no way of knowing the space occupied by these objects could be
temporarily freed-up.
It makes more sense to 'store' this information locally as a memory map
than either using some local storage service (database, gears etc) if
available or, as developers are currently forced to do, de-reference the
object and re-request it at again later (incurring both a latency and
bandwidth cost).
The requirement for obj.kill() arises when the developer/application
knows for sure that a given object is no longer required. It's true that
if the object has been completely de-referenced it will be picked-up
(eventually) by the garbage collector, but it would be nice to be able
to force this behavior.
I hope the above makes some sense, and, apart from re-emphasizing the
practical utility of the above suggestions, I think I'll leave it there.
Thanks,
David Semeria
More information about the es-discuss
mailing list