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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Cheers,
> --MarkM
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
