`free` operator

Alex Russell slightlyoff at google.com
Thu Oct 25 18:04:37 PDT 2012

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> wrote:

> 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
> left.
> > 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
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121025/0ff5e069/attachment.html>

More information about the es-discuss mailing list