3 ms·

TLDR: the entire scope for a closure is retained as long as that environment might still be referenced. There's no such thing as a partial scope in JavaScript (

TLDR: the entire scope for a closure is retained as long as that environment might still be referenced. There's no such thing as a partial scope in JavaScript (to my knowledge, please correct if wrong). In the example, if you don't capture `id` in the returned closure, the problem goes away.

jaffathecake 2y ago
That's not quite right. See the final example in the article, it doesn't reference anything in the parent scope.
- packetlost 2y ago
  Ah, you're right. The fact that a closure exists at all is enough to retain the parent environment.
- deleted 2y ago
  [deleted]
hinkley 2y ago
I know the debugger cannot always show you variables from the originating scope or even completed blocks above the breakpoint so it’s clear that some data not used in the closure becomes unreachable while the closure is still live. But I’ve also spent time hunting down giant memory leaks where some things did get preserved that should not have. I’m so glad domains have finally gone from “deprecated” to deprecated (telling people not to use a feature when you haven’t provided the replacement is fucking stupid) as most of that kind of problem that I can recall involved domains in some manner.
munificent 2y ago
> There's no such thing as a partial scope in JavaScript (to my knowledge, please correct if wrong). There's also no such thing as garbage collection in JavaScript. If you look purely at the language spec, then the language behaves as if there is infinite memory. Garbage collection and how that interacts with scopes is purely an implementation detail. A conforming JavaScript implementation definitely could determine that a given local variable captured by a closure will no longer be accessed and free the associated memory. It's just that the implemented tested by the author (I'm assuming Chrome) doesn't do that.
- packetlost 2y ago
  > There's also no such thing as garbage collection in JavaScript. Incorrect. The details of garbage collection are left to the implementation, but the spec itself at least implies that GC is expected of implementations [0]. The current spec has an entire section on memory management [1] with several constructs for garbage collection and many explicit references to GC. That being said, it would be more correct to say this implementation of JavaScript does not perform capture analysis, effectively creating partial scopes. [0]: https://262.ecma-international.org/7.0/#sec-weakmap-objects https://262.ecma-international.org/7.0/#sec-weakmap-objects [1]: https://tc39.es/ecma262/#sec-managing-memory https://tc39.es/ecma262/#sec-managing-memory
  - munificent 2y ago
    Ah, weak references are a good point. Even so, you can have an entirely conforming JavaScript implementation with no GC. It just means that WeakRefs and WeakMaps will always continue to hold their references.
deleted 2y ago
[deleted]

jaffathecake 2y ago

That's not quite right. See the final example in the article, it doesn't reference anything in the parent scope.

packetlost 2y ago
Ah, you're right. The fact that a closure exists at all is enough to retain the parent environment.
deleted 2y ago
[deleted]

hinkley 2y ago

I know the debugger cannot always show you variables from the originating scope or even completed blocks above the breakpoint so it’s clear that some data not used in the closure becomes unreachable while the closure is still live. But I’ve also spent time hunting down giant memory leaks where some things did get preserved that should not have. I’m so glad domains have finally gone from “deprecated” to deprecated (telling people not to use a feature when you haven’t provided the replacement is fucking stupid) as most of that kind of problem that I can recall involved domains in some manner.

munificent 2y ago

> There's no such thing as a partial scope in JavaScript (to my knowledge, please correct if wrong). There's also no such thing as garbage collection in JavaScript. If you look purely at the language spec, then the language behaves as if there is infinite memory. Garbage collection and how that interacts with scopes is purely an implementation detail. A conforming JavaScript implementation definitely could determine that a given local variable captured by a closure will no longer be accessed and free the associated memory. It's just that the implemented tested by the author (I'm assuming Chrome) doesn't do that.

packetlost 2y ago
> There's also no such thing as garbage collection in JavaScript. Incorrect. The details of garbage collection are left to the implementation, but the spec itself at least implies that GC is expected of implementations [0]. The current spec has an entire section on memory management [1] with several constructs for garbage collection and many explicit references to GC. That being said, it would be more correct to say this implementation of JavaScript does not perform capture analysis, effectively creating partial scopes. [0]: https://262.ecma-international.org/7.0/#sec-weakmap-objects https://262.ecma-international.org/7.0/#sec-weakmap-objects [1]: https://tc39.es/ecma262/#sec-managing-memory https://tc39.es/ecma262/#sec-managing-memory
- munificent 2y ago
  Ah, weak references are a good point. Even so, you can have an entirely conforming JavaScript implementation with no GC. It just means that WeakRefs and WeakMaps will always continue to hold their references.

deleted 2y ago

[deleted]