Garbage collection issues

[bergus]

Your FAQ state

If canceled promises remain pending forever, won't that be a memory leak?

No, it won't.

Can you elaborate on that? I don't believe it.

[rtm]

Isn't that what Benjamin Gruenbaum is saying in http://stackoverflow.com/questions/20068467/do-never-resolved-promises-cause-memory-leak?

[bergus]

Well, he said "I'm assuming you don't keep an explicit reference to it since that would force it to stay allocated.".

That might not always be true. I could of course construct some contrived examples, but it is a general problem where promises are cached or queued. See http://stackoverflow.com/a/18745499/1048572 or http://stackoverflow.com/a/38778887/1048572 for examples of real code.
The more callbacks you chain onto such promises, the more memory is leaked.

Similarly, your canceler promises all have this issue. They are often not resolved, and they always are kept around for the whole time a chain runs (and possibly even longer), exceeding the usual lifetime of a single operation whose resources will be kept around too long.

[rtm]

Thanks for engaging. I have much to learn from you and others about both promises and GC, but my current level of understanding is that things that cannot be GC'd cannot be GC'd, and things that can eventually will be. I don't see how this differs depending whether the promise resolves or is left pending. A resolved/settled promise still could have another then hung off it, so the fact that is was resolved does not in itself make it GC'able.

In the real world, promises are created in semi-transient contexts, such as an Angular component, to take just one example. The component defines promises, some of which may resolve, some of which may not. When the component is torn down, it no longer is referenced from anywhere and anything it itself references, including promises whether resolved or pending, is therefore subject to GC, or am I missing something?

If I have some kind of application-level promise which for ease of discussion let's say is hanging off the window, then right, it cannot be GC'd. But that holds whether it has resolved or not.

I haven't really thought through the issues of caching or queuing promises. I've never actually done that sort of thing, maybe I should. But again, are the relevant GC issues not the same no matter whether the promise is fulfilled or left pending? If you yourself decide to cache something in a semi-global way, then it's hard to complain that it won't be GC'd.

In short, until you convince me otherwise, I have to disagree that whether a promise is fulfilled or not affects its GCability, and that therefore this constitutes an argument against modeling canceled promises as permanently pending, no matter what its other pros and cons.

[bergus]

The problem would not be the promise hanging off the window until it is torn down, it's the things that hang off the promise - i.e. then installed callbacks. OK, your cancel function can solve that problem for the current cancelled promise, but what about other promises? They somehow need to get cancelled as well - either by listening to the same token, uh, canceller promise, or the cancellation state has to propagate downwards. When you just leave them pending and never do anything, this does not happen. This is especially an issue when your cancelled promise is assimilated by an A+ library - which does not know about your cancellation.

[rtm]

There must be something basic I am not understanding. I don't get how the status of a promise, or whether or not something is chained from it, or whether or not those handlers have been invoked or not, affects its GCability.

[bergus]

It does not affect the collectability of the promise, but it does affect the collectability of the callbacks and everything they reference.