So, yes, you can certainly use debugging tools to find which objects
are leaking. But, there are times when you have a program where
something is leaking, and you read through the code, and see that
there is no possible way that it could be leaking (but it is, as
reality sometimes stubbornly refuses to be told what to do.)
Use-after-free bugs are not great, but they are relatively easy to
track down. And, in general, a program that crashes when it does
something wrong, is handling it exactly right. Slowly leaking memory
is much harder to diagnose, and usually much harder to correct.
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 that it's
not so badly architected, but as is so often the case, we didn't
realize the architectural mistakes until we had made them, and fixing
them is quite costly. (Node's http implementation will get a massive
refactor in 0.12.)
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. 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')
}
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.
On Fri, Oct 26, 2012 at 5:11 PM, Patrick Mueller<pmue...@gmail.com> wrote:
On Fri, Oct 26, 2012 at 11:51 AM, John J Barton
<johnjbar...@johnjbarton.com> wrote:
Debugging tools lag other tools in part because test-cases or
use-models are hard not readily available.
But the only debugging tools we really have are proprietary low-level APIs
(eg, V8 debug stuff), and some existing debug ui frameworks (eg, Web
Inspector). The barrier is so, so high for this stuff. Compared to a
number of other environments where the barrier is not so high. Eg, in C, if
you're debugging memory issues, switching to using a debug malloc library
isn't a huge barrier.
It would be nice to lower the barrier, expose some "debug" stuff in JS.
Implying that I want "debug APIs" available in JS, and I want to write my
debug helpers in JS.
V8's --expose-debug-as (or whatever) trick is a step in the right direction.
It would be nice to have some commonality here, so I don't have to write one
set of debug helpers for V8, another for JSC, another for *Monkey, etc.
The js-tools group would be ideal for more discussions of these
issues: https://groups.google.com/forum/?fromgroups=#!forum/js-tools
Ah, nice. I'll stop pestering here, and start pestering there. :-)
--
Patrick Mueller
http://muellerware.org
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
