Explict Memory Managment

David Semeria david at lmframework.com
Fri May 22 13:05:44 PDT 2009


On Fri, 2009-05-22 at 18:34 +0100, Ash Berlin wrote:
> 
> I appreciate the need, but the question arises:
> 
> swapOut to where? To some space that will still use memory, so doesn't  
> actually help....?
> 
Swap out to disk - sorry I thought that was implicit

> 
> Also obj.kill() would be almost [im]possible to actually implement since  
> what would happen if you happen to kill an object that still has  
> references somewhere?
> 
I would say the killed object would just equate to 'null'
If a programmer kills an object and then tries to reference it, then
that's his/her problem

> 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.
> 
Actually, no.

I would assume the work involved in going through every DOM and script
object and working out whether they are islands is non-trivial, whereas 
de-allocating the actual memory for the resulting object list would be.

obj.kill() would actually do the GC a favour, by explcitly referencing
an object which could be deleted. I don't see a huge issue with
'dangling' references to deleted objects.

In fact, these dangling references are frequently hard to spot, and can
lead to major leakage over time.

I know exactly which objects I don't need any more, and I would rather
be able to explictly kill them then make a generic (and expensive) GC
call which may not even guarantee those items will be zapped.




More information about the es-discuss mailing list