`free` operator

Domenic Denicola domenic at domenicdenicola.com
Thu Oct 25 18:09:07 PDT 2012

I do think that including this as a debugging tool is where the most value is. Whether through an engine-provided API (like V8's gc()/--expose-gc) or through something more standardized, like the existing `debugger` statement, is the real question.

On Oct 25, 2012, at 21:04, "Alex Russell" <slightlyoff at google.com<mailto:slightlyoff at google.com>> wrote:

This use-case is usually what weak refs get pressed into service for. But I think that answering your question, "why is my RSS continually increasing?" is something for a tool (debugger, profiler, etc.) to help answer. Some sort of assertion version of free() seems like the right thing: it can communicate your intent there be no refs at that point to a tool. E.g.



On Oct 25, 2012 7:58 PM, "Isaac Schlueter" <i at izs.me<mailto:i at izs.me>> wrote:
On Fri, Oct 26, 2012 at 1:35 AM, Shawn Steele
<Shawn.Steele at microsoft.com<mailto: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<mailto: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<mailto: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.
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121026/8df8dcfc/attachment-0001.html>

More information about the es-discuss mailing list