`free` operator

John J Barton johnjbarton at johnjbarton.com
Fri Oct 26 08:51:20 PDT 2012

On Thu, Oct 25, 2012 at 5:58 PM, Isaac Schlueter <i at izs.me> wrote:
> <johnjbarton at 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


More information about the es-discuss mailing list