Are ES Modules garbage collected? If so, do they re-execute on next import?

Mark S. Miller erights at
Wed Jul 15 06:05:22 UTC 2020

Only a module registry as a whole may be GCed. During the lifetime of any
one module registry, it can only grow. No other solution is possible.

Btw, I remember being surprised ages ago when the same issue came up for
the Java ClassLoader. A classLoader holds on to all the classes it ever
loaded. Each class holds onto its classLoader. Each instance holds on to
its class. During the lifetime of a classLoader or any of its classes, the
graph of that classLoader and its classes can only grow new classes. Not
until the classLoader and all of its classes are unreachable at the same
time can any of them be collected. This was equally unfortunate,
surprising, and inescapable.

On Tue, Jul 14, 2020 at 10:16 PM #!/JoePea <joe at> wrote:

> How can we ensure that long-running applications (even if theoretical),
> that may load and unload an unlimited number of new modules over time
> (f.e. routes in a web page specified by 3rd parties as time
> progresses), not leak memory?
> Even if it is theoretical, I don't like the thought of something that
> only ever allocates memory that will never be freed.
> Is someone working on a solution for this?
> #!/JoePea
> On Wed, Jul 1, 2020 at 6:16 AM Mark S. Miller <erights at> wrote:
> >
> > No, definitely not. The table from specifiers to module instances is
> indexed by specifiers. Specifiers are strings, so this table is not weak.
> It is not a "cache" in the sense that it is allowed to drop things. Rather
> it is a registry of module instances. Only a registry as a whole can be
> gc'ed, and which point that context is no longer around for instantiating
> or reinstantiating modules.
> >
> > As you suggest, if it could drop things because of GC that it would then
> need to regenerate, that would expose the non-determinism of gc. That would
> be a big deal. We carefully designed WeakMaps so that gc was
> non-observable. WeakMaps introduce no observable non-determinism. WeakRefs
> alone expose the non-determinism of gc, and are kept well quarantined from
> the rest of the language.
> >
> >
> > On Tue, Jun 30, 2020 at 5:42 PM #!/JoePea <joe at> wrote:
> >>
> >> I am curious: can modules be garbage collected if the exports are not
> >> references by anything anymore? And if so, will the module be
> >> re-evaluated the next time it is imported?
> >>
> >> I haven't tried an experiment to answer this yet. I'll be back to post
> >> findings if someone doesn't post an official answer first.
> >>
> >> I'm thinking about code longevity. For example, if we make
> >> long-running web-based applications with many routes and features (for
> >> sake of example imagine a desktop environment, or a MMORPG game, with
> >> apps or components that are loaded within the same context). Over
> >> time, if imports are not collected, then it means we have a memory
> >> leak.
> >>
> >> Imagine, for example, an infinite-universe MMORPG where you can land
> >> on different planets where the code for features of a planet are
> >> provided by third parties as ES Modules. I know, this might not be a
> >> safe idea to import any code into an app, but just imagine it for sake
> >> of example (imagine we have a continuous integration system to test
> >> and verify code security, or something, before that code is allowed to
> >> be consumed in the app). Imagine you play this app for many many days,
> >> and visit many places, and you leave the app running the whole time
> >> (because farming for resources is disabled if the app is not running,
> >> or something).
> >>
> >> I would imagine that we want unused modules (when we leave a planet,
> >> for example) to be (destroyed) garbage collected so that we don't
> >> waste memory.
> >>
> >> #!/JoePea
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at
> >>
> >
> >
> >
> > --
> >   Cheers,
> >   --MarkM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list