0

I get a jQuery.Deferred somewhere in my code, and I add several callbacks to it which are member methods of short-lived objects. I was wondering if there are any kind of memory leak potential in this situation, similarly like in .NET event handlers.

I was checking the code of jQuery, but haven't seen any part where callbacks are cleared. I didn't even find where the lifecycle of a deferred object should end.

Could anyone please shed some light on this topic?

EDIT

As I'm thinking about it, it narrows down to this question. In JavaScript, will holding a reference to a member function of an object (not prototype) deny the object from being GC-d? Because jQuery seems to hold these function references in the callbacks of the deferred object.

Zoltán Tamási
  • 12,249
  • 8
  • 65
  • 93
  • I'm not sure how to answer this well. With any language that can hold a reference, there is a risk of memory leaks. It's all about where you take those references and how they fit into the tree that the GC will be looking at. – ssube Nov 29 '16 at 19:48
  • My question is about how jQuery internally handles it, does it dispose the deferred object in some way at some point, etc. – Zoltán Tamási Nov 29 '16 at 19:50
  • This might help: https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/ – Sparrow Nov 29 '16 at 19:54

3 Answers3

1

I'll answer my question because it seems to be a simple one after some thinking. Actually JavaScript functions don't belong "tightly" to the objects where they're defined, unless they are manually bound with Function.prototype.bind for example, but that's another case.

So if functions are living their own life, holding a reference to them should not deny collecting the object where it was originally defined.

Also I have to note that this all doesn't even matter if I don't hold a direct or closured reference to the deferred object itself, because then whenever it's done the job (resolved/rejected) it will be collectible.

Please someone more experienced correct me if any assumption is wrong here.

Zoltán Tamási
  • 12,249
  • 8
  • 65
  • 93
1

I haven't seen any part where callbacks are cleared.

The callbacks are cleared when the promise is settled (fulfilled or rejected).

I didn't even find where the lifecycle of a deferred object should end.

The lifecycle of a promise ends when nothing holds a reference to it any more.

There are generally two things that hold a reference to it: the resolver (e.g. timeout, ajax request etc) that eventually will settle the promise, and entities that store the promise because they want to use it (i.e. its result) later. The promise object in turn holds a reference to all the callbacks (until settled), and to the result value (since settled).

A leak can occur if the promise is never resolved, has callbacks attached to it, and is prevented from being garbage-collected by some references. That's very rare though.

In JavaScript, will holding a reference to a member function of an object (not prototype) deny the object from being GC-d?

No, in general not. There are no "members" in javascript, just plain standalone functions.

Though of course the function, when being a closure, could hold a reference to the object, and would keep it from being collected.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • Thank you, I'm happy that my own answer is mostly consistent with yours. I'm working every day both with .NET and JS and sometimes I tend to get confused. – Zoltán Tamási Nov 29 '16 at 20:40
  • For the record - the term "members" is used in javascript especially by Douglas Crockford, eg [here](http://www.crockford.com/javascript/private.html), though the meaning is different from that implied by the OP. – Roamer-1888 Dec 02 '16 at 03:35
0

From what I've seen (and some light reading: Do never resolved promises cause memory leak?), there is negligible impact from unresolved Promises -- or Deferrereds -- unless you are:

  • Creating a large number: hundreds of instances of any object are a drag that requires special handling and design
  • Maintaining references to instances that prevent a GC run from cleaning up any out-of-scope items
Community
  • 1
  • 1
Ishan Chatterjee
  • 825
  • 8
  • 21