Risto (Jul 01 2020 at 16:29): Risto (Jul 01 2020 at 16:29):It seems that there is a way to load multiple wasms to modules and then instantiate them and let them work together.
However, is there a way to unload one of the modules afterward in some way? I cannot seem to be able to find an API to unload a module. I am not quite sure what unloading would entail. I would expect unloading would at least remove the module's code from being accessible to other modules (through a table for example).
Risto (Jul 01 2020 at 17:05):I guess the docs added here just 5 minutes ago answer my question: https://github.com/bytecodealliance/wasmtime/pull/1955
And the answer is that there is no unloading of a single module at this time. The only way to unload data is to drop the store, which drops all the instances.
"once and instance is created within a Store it will not be deallocated until all references to the Store have gone away".
Alex Crichton (Jul 01 2020 at 17:07):Heh glad I could preemptively answer your question :)
But yes, there's no way to preemptively drop instances/modules because wasmtime does not have a garbage collector for instances/modules
Alex Crichton (Jul 01 2020 at 17:08):and once something is instantiated into a Store the Storeholds onto it until the end of its lifetime
Risto (Jul 01 2020 at 17:30):I started thinking about recreating all instances, but that seems a bit difficult as callstacks would be a problem and table references and similar might also be problematic. Maybe a good workaround, at least for the time being, is just to try minimize the impact of an "unloaded" module. This could be done at least by removing all references to it so other modules can use those table slots for their references and freeing the memory related to the module (if possible).
Yury Delendik (Jul 01 2020 at 17:34):there is memory consumed by the modules (it is mostly code) and instances (mostly rest of it). Question is what needs to be unloaded: code or instance resources?
Yury Delendik (Jul 01 2020 at 17:40):@Risto notice that solution to unloading of one module maybe is just to keep some Module alive, but recreate store and all instances (since they are part of the entire program graph).
Risto (Jul 01 2020 at 17:49):Preferably everything related to a module and its instance would be unloaded.
The allocated memory is tricky since you can basically allocate some memory and pass a pointer to it to another module. In practice, unloading the allocated memory would be a concern for the developer of the module and the creator of the environment where the module runs. Unloading of memory is not something the runtime would try to solve as a general case in my view. Similarly, an issue is the table, which can contain references to the functions. One concern is the exports of a module that may be imported by another module. I would maybe expect such a case to cause some kind of trap if unload is attempted. Apart from the shared resources, I would guess/hope the unloading of other parts should be relatively straight forward.
It seems that emscripten is providing some kind of convention of cleanup function in a module, which could allow a module execute some deallocation code before being unloaded.
These are just some thoughts I have from the top of my head regarding your question about what would need to be unloaded.
Alex Crichton (Jul 01 2020 at 17:52):It's possible that we could implement other schemes, but we do not have it implemented right now the ability to track down where a module is being referenced
Alex Crichton (Jul 01 2020 at 17:52):that'd basically amount to a GC which hasn't currently been implemented
Risto (Jul 01 2020 at 17:52):@Yury Delendik Hmm, what is the use in keeping a Module alive? In my understanding, a module does not hold any data regarding the state of a program. Keeping a module alive would only speed up the recreation of instances maybe.
Think there is too much of the word "module" in these posts :D
Last updated: Oct 23 2024 at 20:03 UTC