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

Herby Vojčík herby at mailbox.sk
Thu Jul 16 15:24:08 UTC 2020


On 16. 7. 2020 15:23, Guy Bedford 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 

I understand there may be problems with static imports that are 
statically analyzed, and there "only GC module loader as whole" makes 
sense, but maybe, it would be possible to treat _dynamically loaded_ 
modules different way? Just thinking aloud.

> 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 gmail.com 
> <mailto:erights at gmail.com>> 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 trusktr.io
>     <mailto:joe at trusktr.io>> 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 gmail.com
>         <mailto:erights at gmail.com>> 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 trusktr.io
>         <mailto:joe at trusktr.io>> 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 mozilla.org <mailto:es-discuss at mozilla.org>
>          >> https://mail.mozilla.org/listinfo/es-discuss
>          >
>          >
>          >
>          > --
>          >   Cheers,
>          >   --MarkM
> 
> 
> 
>     -- 
>        Cheers,
>        --MarkM
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 




More information about the es-discuss mailing list