`free` operator

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Oct 25 18:24:13 PDT 2012

if you are holding it already plus you don't know what happens after that
assertFree(obj) call I am not sure about the value of this assertion.

On Thu, Oct 25, 2012 at 6:04 PM, Alex Russell <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.
>    console.assertFree(obj);
> Regards
> 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
> _______________________________________________
> 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/03c67693/attachment.html>

More information about the es-discuss mailing list