Explict Memory Managment

[Ash Berlin]

On 22 May 2009, at 16:21, David Semeria wrote:

> 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


I appreciate the need, but the question arises:

swapOut to where? To some space that will still use memory, so doesn't  
actually help....?


Also obj.kill() would be almost possible to actually implement since  
what would happen if you happen to kill an object that still has  
references somewhere?

What you actually want is just a gc() method avilable somewhere that  
will do a normal GC run, just on demand isn't it? This is certainly  
more likely to happen.

I guess obj.kill() could just see if the object is reachable and if it  
still is then do nothing, or throw, but still.

-ash