Explict Memory Managment
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.
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