Garbage collection in generators

[Andreas Rossberg]

On 17 February 2016 at 09:08, Benjamin Gruenbaum <benjamingr at gmail.com>
wrote:

> In the following example:
>
> ```js
>
> function* foo() {
>     try {
>        yield 1;
>     } finally {
>         cleanup();
>     }
> }
> (function() {
>   var f = foo();
>   f.next();
>   // never reference f again
> })()
>
> ```
>
>  - Is the iterator created by the function `foo` ever eligible for garbage
> collection?
>

The spec does not talk about GC, but in typical implementations you should
expect yes.


>  - If it is - does it run the `finally` blocks?
>

No, definitely not. Try-finally has nothing to do with GC, it's just
control flow. If you starve a generator it's not going to get completed,
just like other control flow won't. (Which is why some of us think that
iterator `return` is a misfeature, because it pretends to provide a
guarantee that does not exist, and only encourages bogus forms of resource
management.)


Related resources:
>
>  - Python changed the behavior to "run `return` on gc" in 2.5
> https://docs.python.org/2.5/whatsnew/pep-342.html
>  - C# doesn't run finalizers, but iterators are disposable and get aborted
> automatically by foreach (for... of) - on break. this is similar to what we
> do:
> http://blogs.msdn.com/b/dancre/archive/2008/03/14/yield-and-usings-your-dispose-may-not-be-called.aspx
>  - PHP is debating this issue now, I was contacted by PHP internals people
> about it which is how I came into the problem in the first place:
> https://bugs.php.net/bug.php?id=71604
>  - Related issue I opened on async/await :
> https://github.com/tc39/ecmascript-asyncawait/issues/89
>

Even if we want to make GC observable via finalisation, then it should at
least be done in a controlled and explicit manner rather than silently
tacking it onto an unrelated feature. See the revived weakref proposal.
Python's idea is just confused and crazy.

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160217/b50e6831/attachment.html>