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

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Jul 16 13:44:37 UTC 2020


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 gmail.com> 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 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> 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> 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> 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
>>> >> https://mail.mozilla.org/listinfo/es-discuss
>>> >
>>> >
>>> >
>>> > --
>>> >   Cheers,
>>> >   --MarkM
>>>
>>
>>
>> --
>>   Cheers,
>>   --MarkM
>> _______________________________________________
>> es-discuss mailing list
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200716/7135e308/attachment-0001.html>


More information about the es-discuss mailing list