Replies: 1 comment 1 reply
-
No, the GC doesn't know about any allocations in the wasm linear memory, and doesn't know that close() free's memory or that open() allocates it. In other words, its can't/doesn't reason about the links between GC objects and regions of linear memory. That doesn't mean it won't run though. Trying to second guess if/when GC might run is probably not worth its since its no something is observable or to be relied upon. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a question about memory management. I'm targeting Node.js but I don't know if that is relevant.
Assume I have two C functions which I compile to Wasm with emscripten:
open()
: basically allocates memoryclose(handle)
: frees the allocated memoryI call
open()
in JavaScript when I create a new instance of the classResource
.When I don't need
res
anymore, I have to callres.finalize()
to free the memory.If I don't call
res.finalize()
, I create a memory leak.Recently,
FinalizationRegistry
was introduced. Instead of manually callingres.finalize()
, I could do something likeWhen the garbage collector (GC) reclaims
res
, it also leads to a call toclose()
(possibly much later, though).This would free the allocated memory at some point. I don't really care for when exactly this happens, so it should be fine.
However, what I'm wondering is whether the memory allocated in
open()
impacts the GC at all. Or can it happen that the GC is not triggered, because there are only very few unreachable JavaScript objects (GC thinks it's not worthwhile running), even thoughopen()
has allocated vast amounts of memory? After all, the GC does not know the connection between the allocated memory andres
, i.e. it doesn't know that it could free memory by just reclaimingres
.I hope it is more or less clear what I'm struggling with.
Any thoughts are appreciated.
Beta Was this translation helpful? Give feedback.
All reactions