Of course we are not going to add *unsafe* manual memory management to
JS. No need to worry about that!
Isaac proposed safe yet horribly inefficient memory management, whereby
any unwanted strong refs are found (by a global scan) and then nulled or
set to undefined. This is bad for the reasons given on the thread, but
also because it requires a full GC in general.
Safe and efficient manual memory management is a feature of Rust and
other languages which range from "Research" to (at best) "Advanced
Technology", and which seem to require fancy type/ownership systems.
As a debugging tool, something like Alex's assertFree (of course, you
couldn't have a weak ref to pass in, so maybe assertSingleRef is a
better name) could be done. Again, in some (many high performance)
implementations, it would require a full mark/sweep GC. So it is a
debug-build or debug-mode only tool, not to be used lightly.
What I did years ago as a debugging tool in SpiderMonkey, which I
believe survives in the JS_DumpHeap C API, is along these lines. Rather
than null any leaky paths to cover up the bug, it dumps all paths by
which the allegedly single-ref (or just mysteriously still-alive)
GC-thing-to-find that you pass in as an optional parameter still is
connected to the graph of rooted live things.
The path names are formed by property names with unambiguous or
sufficiently unlikely separators. Internal strong refs (e.g., roots in
native data structures held as opaque or private parts of a JS object,
e.g. a DOM object peering a C++ struct or class instance) may be given
constant-string names when made strong (rooted).
Usually when debugging a leak, getting the set of strong-ref paths leads
quickly to progress in fixing the bug.
/be
David Bruant wrote:
2012/10/26 Isaac Schlueter <[email protected] <mailto:[email protected]>>
(...)
We've got some band-aids in place in the node http.js file to prevent
parser leaks. A more forcible free() method would have made it much
easier. The long-term solution is to rewrite the program (...)
So you're suggesting that a language-level feature with abusive
authority introducing use-after-free bugs (and maybe others) should be
included to solve short-term problems?
Yehuda's "action at a distance" complaint is definitely a valid
concern. However, note that an object can't be freed unless you have
a reference to the object.
Everyone has a reference to built-ins so a bug or an attacker could
free built-ins.
Thus, any code that would set my reference
to undefined could only do so if it was also capable of mutating the
object in any other way (adding/removing properties, etc.)
So, we already have this:
function () {
// acquire a ref from some external code
// no way of knowing what else is sharing this object
var x = func()
x.foo = 'bar'
// other code...
doAnotherThing()
// not guaranteed!
assert(x.foo === 'bar')
}
With non-configurable properties and making objects non-extensible,
you have a way to prevent this, a way to protect your objects from
"action at a distance". Even proxies are required to respect some
invariants for the sake of application securability.
The free operator you're proposing cannot be protected against. Anyone
can release any object it has a reference to without the object
creator (or the other object reference holder) having their word to
say to prevent it. That's unbalanced.
Whenever you have a reference to an object that is shared with some
other code, there's the potential for action at a distance. The
proposal here is to make that action a bit more powerful.
I don't agree that it's necessarily a problem in production. We free
objects in other languages all the time.
I agree with you, C and C++ are absurdly unsafe languages. No wonder
double free and use after-free bugs are so common! As the rumor goes,
use-after-free bugs lead to security issues sometimes [1]. Really not
an example to follow in my opinion.
What do you think about the revokable proxy solution? I agree it's
less sexy than a 4-letter keyword operator, but it's close enough to
standard and seems to solve your short-term issue as efficiently.
Tom's shim [2] simulates the direct proxy API on top of the current
V8's one. It includes revokable proxies I see. It can work today (as
in Sat Oct 27th 2012) I think.
David
[1] http://www.mozilla.org/security/announce/2012/mfsa2012-85.html
(just pick the first result Google gave me against "use after free
security").
[2] https://github.com/tvcutsem/harmony-reflect
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
