`free` operator

Isaac Schlueter i at izs.me
Thu Oct 25 17:58:05 PDT 2012

On Fri, Oct 26, 2012 at 1:35 AM, Shawn Steele
<Shawn.Steele at microsoft.com> wrote:
> I sort of have a fundamental problem with the solution.  Eg:  If it were actually unused, it'd be GC'd.  Since it isn't GC'd, something must be holding a reference to it.  So if you force it to be gone, or clear all the properties, or whatever, seems to me that then you'd just start throwing random errors in the code that tried to use the "freed" object?  That might be even harder to track down.

On the contrary, "TypeError: Cannot read property 'prop' of
undefined", with a stack trace, is WAY easier to track down than "The
RSS on my server gradually rises, until the operating system kills it,
which happens about every 4 hours."

Fast failure is not as good as success, but it's better than anything else.

> On Thu, Oct 25, 2012 at 4:16 PM, Isaac Schlueter <i at izs.me> wrote:
>> It'd be really nice if JS had a way to explicitly delete an object.
> I guess you mean ... a way to set all the refs to a object to undefined.

Yes, exactly.

On Fri, Oct 26, 2012 at 1:20 AM, John J Barton
<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.

> Since you know "obj" can you set it to be a getter that returns undefined?

Yeah, but the purpose of this is to take *away* the ref that you
already *have*.  What good is a getter that returns undefined, once
you've already gotten it?  Closing the barn door after the horse has

> Deleting all of the properties of obj would solve the problem as well I assume.

But that is a bit more whack-a-mole, and expensive.  Ultimately, what
we did was move all of the addon properties on parsers to a single
object, and delete that object when we re-use the http parser.

More information about the es-discuss mailing list