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 <guybedf...@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 <erig...@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 <j...@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 <erig...@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 <j...@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@mozilla.org >>> >> https://mail.mozilla.org/listinfo/es-discuss >>> > >>> > >>> > >>> > -- >>> > Cheers, >>> > --MarkM >>> >> >> >> -- >> Cheers, >> --MarkM >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
