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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to