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

Andrea Giammarchi andrea.giammarchi at
Thu Jul 16 13:55:10 UTC 2020

On a second thought ... couldn't `import.meta.cache`, or something similar,
be implemented in NodeJS only?

On Thu, Jul 16, 2020 at 3:44 PM Andrea Giammarchi <
andrea.giammarchi at> wrote:

> FWIW explicit eviction is not only fine, if you own the code that does
> that, but the only way I can code cover 100% all the branches of my
> libraries. The issue here is the untrusted Web, where I'd never expect any
> 3rd parts library to evict a module I am using within my code ... like ...
> ever.
> Accordingly, I think Allen, if it was Allen, made the right call for ESM.
> On Thu, Jul 16, 2020 at 3:23 PM Guy Bedford <guybedford at> wrote:
>> Node.js in the CommonJS loader and dynamic loaders like SystemJS have
>> supported module unloading for many years by permitting eviction from the
>> loader registry. Evicting the full parent tree was the traditional
>> reloading workflow in SystemJS, but live binding pushes are also permitted
>> in SystemJS as well for this.
>> I agree there are issues and invariants of course to consider from a
>> theoretical perspective, but those are decisions to be made in terms of
>> what invariants are valued, and I don't feel they are necessarily absolute
>> constraints. These decisions should be made based on what is best for
>> the JS users and engines. Not that I feel strongly this should be a
>> requirement but that it should still be open to consideration.
>> I'm not sure it was Allen's intention to ban any concept of reloading
>> modules when defining the idempotency requirement for the host resolve
>> function. Perhaps he could speak to that if he's around.
>> On Tue, 14 Jul 2020 at 23:05, Mark S. Miller <erights at> wrote:
>>> 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
>>> --
>>>   Cheers,
>>>   --MarkM
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list