Post AkSh85wcWVFRxVIbg0 by jaffathecake@mastodon.social
(DIR) More posts by jaffathecake@mastodon.social
(DIR) Post #AkSh85wcWVFRxVIbg0 by jaffathecake@mastodon.social
2024-07-30T16:33:50Z
0 likes, 0 repeats
đź“ť JavaScript garbage collection doesn't work how I expected when it comes to closures. TIL!https://jakearchibald.com/2024/garbage-collection-and-closures/
(DIR) Post #AkShzbrMasXaI2MG8W by gundersen@mastodon.social
2024-07-30T16:43:24Z
0 likes, 0 repeats
@jaffathecake and the reason? Is it because it would be a lot of work to recalculate what can be garbage collected and what can't inside a closure after each dereference, when in most cases it's nothing? It could pay of in situations like this but in the vast majority of scenarios it's not worth it?
(DIR) Post #AkSi4kouhr7pWofJ6e by jaffathecake@mastodon.social
2024-07-30T16:44:58Z
0 likes, 0 repeats
@gundersen I'm not entirely sure. @mathias do you know?
(DIR) Post #AkSv10IoV65Nn8C0iO by ashley@fosstodon.org
2024-07-30T19:10:08Z
0 likes, 0 repeats
@jaffathecake hopefully obvious to most readers that this isn't how the language is spec'ed it's how most popular engines implement their closures.I've been toying with a build plugin which re-writes code like this to avoid the closure sharing. Really want to get it working well enough to try on a big app and see if it reduces peak memory.
(DIR) Post #AkSy666OfG1n5bVOHA by dotproto@toot.cafe
2024-07-30T19:43:58Z
0 likes, 0 repeats
@jaffathecake > Now bigArrayBuffer is GC'd, since nothing within the scope is callable.Nit: It's now able to be GC'd, but we don't know *when* that will happen.Suggestion: "Now bigArrayBuffer can be GC'd, since nothing within the scope is callable."
(DIR) Post #AkTDxprMlgNrfFYbey by lapcatsoftware@mastodon.social
2024-07-30T22:42:28Z
0 likes, 0 repeats
@jaffathecake Of course the top voted HN comment on the article is wrong.
(DIR) Post #AkTE1O3M5uh6a8rHtI by ashley@fosstodon.org
2024-07-30T22:43:03Z
0 likes, 0 repeats
@jaffathecake @gundersen @mathias Some info here:https://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.htmlAnd:https://issues.chromium.org/issues/41070945
(DIR) Post #AkTh7XC7uuBNLGFEhs by jaffathecake@mastodon.social
2024-07-31T04:09:11Z
0 likes, 0 repeats
@lapcatsoftware naturally
(DIR) Post #AkU4ccZmFxxBxH6EGe by jaffathecake@mastodon.social
2024-07-31T08:32:32Z
0 likes, 0 repeats
Some updates:➡️ An IIFE is enough to trigger this leak➡️ It's a cross-browser issue➡️ There are other articles on this (some lower-level)➡️ No, this isn't due to eval()https://jakearchibald.com/2024/garbage-collection-and-closures/#updates
(DIR) Post #AkU6wrRqs6O7mRAg0u by brawaru@mstdn.social
2024-07-31T08:58:29Z
0 likes, 0 repeats
@jaffathecake oh jeez. someone should write an ESLint rule for that đź’€
(DIR) Post #AkUHKcZgp1GQ8so12m by pygy@mamot.fr
2024-07-31T10:54:56Z
0 likes, 0 repeats
@jaffathecake I think that this is because JS GC works per scope rather than per variable.Lua has a more granular approach to lexical scope, with the upvalue mechanism, which is explained here:https://www.jucs.org/jucs_11_7/the_implementation_of_lua/jucs_11_7_1159_1176_defigueiredo.html#:~:text=5%20Functions%20and%20Closures
(DIR) Post #AkUV4DgL0Hp7fCzMFE by erickjm@mastodon.online
2024-07-31T13:28:50Z
0 likes, 0 repeats
@jaffathecake I knew this but probably forget about it. I remember learning about it because Ember or jQuery had the issue and Yehuda Katz wrote a blog post about it or it was in a podcast many years ago. I can't find the reference though unfortunately.
(DIR) Post #AkUdRIxSLv5mJxVxY0 by allenwb@mastodon.social
2024-07-31T15:02:35Z
0 likes, 0 repeats
@jaffathecake This is definitely a naive implementation issue, not a language design issue. Various approaches to make this work, with varying compile-time/runtime perf trade-offs. But really needs to be addressed in an implementation's low level design for representing environments and closures. Hard to retro fix in mature implementations. I can understand why nobody wants to touch this for these mature engines.
(DIR) Post #AkUhoOlDLQJqnJ3W08 by Drarok@mastodon.social
2024-07-31T13:38:11Z
0 likes, 0 repeats
@pygy @jaffathecake that would have been my guess, it does make sense even if it’s surprising.I’m guessing JS doesn’t have a way to explicitly list variables to capture to mitigate this case-by-case? I’ve not written any in ages…
(DIR) Post #AkUhoPc2B2ZPR7lhKa by pygy@mamot.fr
2024-07-31T13:41:15Z
0 likes, 0 repeats
@Drarok @jaffathecake There's no need for explicitly marking them, the lua `local` binding works almost like the JS `let` (but it allows shadowing). The scenario described by Jake doesn't leak in Lua.It is "just" a matter of changing the runtimes, no need for custom language semantics tweaking.
(DIR) Post #AkUhoQGRkmtdSSfyK0 by pygy@mamot.fr
2024-07-31T13:43:00Z
0 likes, 0 repeats
@Drarok @jaffathecake To answer your question (I almost forgot, sorry), there's no mechanism to sidestep the issue in JS currently, because of suboptimal runtime semantics.
(DIR) Post #AkUhoQurKXDrTnaFJQ by jaffathecake@mastodon.social
2024-07-31T15:51:37Z
0 likes, 0 repeats
@pygy @Drarok you can set values to null or whatever when they're no longer needed.
(DIR) Post #AkUxZkGCj0b4OiaNV2 by pygy@mamot.fr
2024-07-31T18:46:53Z
0 likes, 0 repeats
@jaffathecake @Drarok That's only a partial solution, it isn't always possible to track references.
(DIR) Post #AkXfFMvcY0z8XgyJyC by nolan@toot.cafe
2024-08-02T02:06:42Z
0 likes, 0 repeats
@jaffathecake Great writeup, I had no idea about this. The linked React example is horrifying.