<br><br><div class="gmail_quote">On Thu, Oct 25, 2012 at 9:04 PM, Alex Russell <span dir="ltr"><<a href="mailto:slightlyoff@google.com" target="_blank">slightlyoff@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<p dir="ltr">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.</p>



<p dir="ltr">   console.assertFree(obj);</p></blockquote><div><br></div><div>Glad you brought this up.</div><div><br></div><div>While there are two weak ref strawman proposals, I've also asked Nate Rajlich to write up a rationale and approach document re: his experience with node-weak[0] to add to known resources.</div>

<div><br></div><div><br></div><div>Rick</div><div><br></div><div> </div><div>[0] <a href="https://github.com/TooTallNate/node-weak">https://github.com/TooTallNate/node-weak</a></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<p dir="ltr">Regards</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Oct 25, 2012 7:58 PM, "Isaac Schlueter" <<a href="mailto:i@izs.me" target="_blank">i@izs.me</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


On Fri, Oct 26, 2012 at 1:35 AM, Shawn Steele<br>
<<a href="mailto:Shawn.Steele@microsoft.com" target="_blank">Shawn.Steele@microsoft.com</a>> wrote:<br>
> 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.<br>



<br>
On the contrary, "TypeError: Cannot read property 'prop' of<br>
undefined", with a stack trace, is WAY easier to track down than "The<br>
RSS on my server gradually rises, until the operating system kills it,<br>
which happens about every 4 hours."<br>
<br>
Fast failure is not as good as success, but it's better than anything else.<br>
<br>
<br>
> On Thu, Oct 25, 2012 at 4:16 PM, Isaac Schlueter <<a href="mailto:i@izs.me" target="_blank">i@izs.me</a>> wrote:<br>
>> It'd be really nice if JS had a way to explicitly delete an object.<br>
><br>
> I guess you mean ... a way to set all the refs to a object to undefined.<br>
<br>
Yes, exactly.<br>
<br>
<br>
On Fri, Oct 26, 2012 at 1:20 AM, John J Barton<br>
<<a href="mailto:johnjbarton@johnjbarton.com" target="_blank">johnjbarton@johnjbarton.com</a>> wrote:<br>
>> var obj = {}<br>
>> var foo = { ref: obj }<br>
><br>
> I assume that in your real life, you don't know 'foo' but somehow you<br>
> know that foo.ref is never used?<br>
<br>
Well, you know that IF foo.ref is used, it's an error, and ought to<br>
throw.  Also, it's quite easy to check if the property exists, and set<br>
it to a new object if so.  It's common to have things like:<br>
<br>
if (!this._parser) {<br>
  this._parser = new ParserThingie();<br>
}<br>
<br>
In this example, imagine that parsers are expensive to create.  So, we<br>
try to reuse them (danger!), and over time, our program grows until we<br>
have some code paths where the parsers are not getting all of their<br>
data removed properly.  If the parser has a ref to an object that has<br>
a reference to some other thing, etc., then you've got a memory leak.<br>
<br>
This exact situation happened in Node's HTTP library a few months ago,<br>
and was very tedious to fix.  We quite easily identified one of the<br>
things in the chain, and that it must have been linked in some way to<br>
an HTTP parser (or else it would have been GC'ed).<br>
<br>
It would have been much easier to just find the point where we know<br>
that the HTTP response object should be "finished", and forcibly<br>
remove any references to it.<br>
<br>
<br>
> Since you know "obj" can you set it to be a getter that returns undefined?<br>
<br>
Yeah, but the purpose of this is to take *away* the ref that you<br>
already *have*.  What good is a getter that returns undefined, once<br>
you've already gotten it?  Closing the barn door after the horse has<br>
left.<br>
<br>
<br>
> Deleting all of the properties of obj would solve the problem as well I assume.<br>
<br>
But that is a bit more whack-a-mole, and expensive.  Ultimately, what<br>
we did was move all of the addon properties on parsers to a single<br>
object, and delete that object when we re-use the http parser.<br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br>