Menu
I am using dynamic import to load scripts written by the user in the browser. I start by placing the script contents into a blob, then I use dynamic import() to load the script as a module. Over time, I expect these scripts to change and be destroyed, and thus for the corresponding modules to be garbage collected. However, based on memory profiling in Chrome, that is not happening.
The reason why seems to be related to something called the ModuleMap. Here's a screenshot from a memory snapshot I took after all scripts were no longer in use.
As you can see, the Window object is is providing a retaining path down to these modules. As long as that is the case, I'm sure to eventually run out of memory, since these modules are created each time the user edits their script.
I'd like to know if there's a way to get Chrome (and other browsers) to unload these modules once they are no longer in use.
968
One fundamental problem with garbage collection, though, is that it is difficult to estimate and manage the actual size of the working set in memory, because garbage collector can free your memory only delayedly. So, yes, when memory is restricted, garbage collection might not be a good choice.
Garbage collection (GC) can have a big impact on the performance of your apps. GC is a process that the Node. js runtime regularly runs to clean up any objects that were created and are not used anymore. If you create a lot of objects in your code (or a dependency does) this can slow down your app.
The garbage collector searches for reachability from the root object to determine whether an object will be used in the future or not. For interlinked objects, it searches whether an object has no incoming edge, then that object cannot be reached, so it removes that object from the memory.
The garbage collection process only starts when a new object comes in and find no more place for it in the from-space. Then it traverses a old-to new root set to figure out whether the object is still alive and whether it has been survived from the last round. If the object is no longer used, leave it there.
I'm getting the sense from this spec that maybe the answer is that you cannot cause modules to be unloaded. This is because any given module must only be parsed once per Document worker. There's no way for me to promise that I'll never use the module from a given URL again once I've thrown it away, thus there's no way for the ModuleMap to allow things to be collected.
And, indeed, reading through the Chromium source code, I don't see any calls to UnregisterModuleScript. It's entirely possible that this is not all the relevant code, but if it is, it stands to reason that any given instance of ModuleMap is going to hang on to its modules forever.
It seems like in theory I might be able to get the desired behavior from WebWorkers, since they have a different global scope. If anyone can tell me whether I'm barking up the right tree, that would be helpful.
148
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
