On Thu, Oct 25, 2012 at 5:58 PM, Isaac Schlueter <i...@izs.me> wrote: > <johnjbar...@johnjbarton.com> wrote: >>> var obj = {} >>> var foo = { ref: obj } >> >> I assume that in your real life, you don't know 'foo' but somehow you >> know that foo.ref is never used? > > Well, you know that IF foo.ref is used, it's an error, and ought to > throw. Also, it's quite easy to check if the property exists, and set > it to a new object if so. It's common to have things like: > > if (!this._parser) { > this._parser = new ParserThingie(); > } > > In this example, imagine that parsers are expensive to create. So, we > try to reuse them (danger!), and over time, our program grows until we > have some code paths where the parsers are not getting all of their > data removed properly. If the parser has a ref to an object that has > a reference to some other thing, etc., then you've got a memory leak. > > This exact situation happened in Node's HTTP library a few months ago, > and was very tedious to fix. We quite easily identified one of the > things in the chain, and that it must have been linked in some way to > an HTTP parser (or else it would have been GC'ed). > > It would have been much easier to just find the point where we know > that the HTTP response object should be "finished", and forcibly > remove any references to it.
Debugging tools lag other tools in part because test-cases or use-models are hard not readily available. Bugs by their nature are mysterious when unsolved and embarrassing when solved. Example code for this case with insight on why it was hard could generate competition to create tools to solve similar cases. Benchmarks for debugging tools are badly needed. The problem you outlined has two very different phases. First is to isolate the leaker. This is a hard problem; recent improvements in Chrome devtools HeapProfiler can help. Second is plugging the leak, the problem you posted about. The analysis of a program by combined source and runtime analysis is the kind of problems I'm working on. Specific cases would be really helpful. The js-tools group would be ideal for more discussions of these issues: https://groups.google.com/forum/?fromgroups=#!forum/js-tools jjb _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss