As Ash points out, there's no memory-safe way to implement obj.kill()
short of a full GC.
There is no way JS will lose memory safety, ever!
What's more, we shouldn't expose a gc() call. It would only be abused
over time. Even if it were used well at first for a given browser
engine (or version), the tendency over time would be for it to be
called too much, and for too many (or all) user agents. It would be
symptom-treating at best.
Explicit memory management is sometimes important, e.g. using a
preallocated array or native buffer when pushing pixels. This is not a
case where gc() or obj.kill() helps, though.
If you find poor GC performance, file a bug with the browser vendor or
open source project. If you are using too much memory, reifying large
external data sets in JS, don't do that. There's usually a way to
avoid taking the all-in-memory hit. SAX-style parsing rather than all-
or-nothing blocking parse calls, etc.
I hate to generalize, but on the other hand the post asking for
explicit memory management was short on specific details -- including
ones that might lead to specific browser bugs that could be fixed to
the benefit of all developers.
/be
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss