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.
console.assertFree(obj);
Regards
On Oct 25, 2012 7:58 PM, "Isaac Schlueter" <i...@izs.me> wrote:
> On Fri, Oct 26, 2012 at 1:35 AM, Shawn Steele
> <shawn.ste...@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...@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
> <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.
>
>
> > 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
