The spec and implementation are exactly defined like this - v8 directly
provides HostResolveImportedModule exactly to the spec, returning a module
object for a given specifier and module parent. By default in v8 modules
are GC'able objects... they don't implement registries currently. There's
just
For the web, one could lock it down with CORS-like restrictions, too,
so a script from one domain isn't allowed to modify cached entries
from another domain. It's not insurmountable.
This is part of why I feel the invariant should be removed and the
spec should just internally resolve static
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
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.giammar...@gmail.com> wrote:
> FWIW explicit eviction is not only fine, if you own the code that does
> that, but the only way I
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.
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
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.
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
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,
That's part of the caching I'm referring to. And if the cache entry
for it has been evicted, I would *not* expect it to necessarily return
the same instance, consistent with the behavior with `require` and
`require.cache` in Node (and similar with most other module loaders
that support cache
even if dereferenced, a dynamic import could re-reference it any time, and
I would expect it to still be the same module, it'd be a surprise otherwise
(cached things, same namespace checks, etc).
On Wed, Jul 1, 2020 at 7:33 AM Isiah Meadows
wrote:
> Just to expand on that, if the module record
Just to expand on that, if the module record itself is dereferenced
(like if it's evicted from the cache somehow), then yes, it should be
collected as appropriate. However, I'm not aware of any major
implementation that offers that functionality.
-
Isiah Meadows
cont...@isiahmeadows.com
Modules in the spec are cached by specifier by modules that import them.
Modules in major implementations are additionally cached for the entire
realm by absolute URLs. I would say that for actual code (functions and
classes and whatnot) leaks aren't really a problem. Even if you import a
ton of
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
14 matches
Mail list logo
