In the following module graph:
0.html
+---- 1.mjs
+---- non_existing.mjs
+---- 3.mjs
+----- 2.mjs
+---- 3.mjs
Both 1.mjs and 2.mjs have a common submodule called 3.mjs
But 1.mjs also has a non-existing submodule, so we can't instantiate the
module graph of 1.mjs. which in turn will cancel 3.mjs
But 3.mjs is also a sub-module of 2.mjs, so in order to instantiate the
module graph of 2.mjs, we skip canceling 3.mjs when we processed 1.mjs
Differential Revision: https://phabricator.services.mozilla.com/D209210
Dynamic import is prevented by IsDynamicImportSupported, and now it now throws
TypeError instead of Error, and related wpt passes with it.
Differential Revision: https://phabricator.services.mozilla.com/D202494
Currently we record the URI of each fetching modules and any addtional requests
that are blocked waiting on that fetch. This adds the fetching module request
itself.
This is needed by the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D204201
Currently we record the URI of each fetching modules and any addtional requests
that are blocked waiting on that fetch. This adds the fetching module request
itself.
This is needed by the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D204201
Currently we record the URI of each fetching modules and any addtional requests
that are blocked waiting on that fetch. This adds the fetching module request
itself.
This is needed by the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D204201
On the main thread, single mozJSModuleLoader instance is shared across all
loads in non-shared global, with resetting the internal state after importing
a module graph.
NonSharedGlobalSyncModuleLoaderScope manages the lifetime of each usage.
Import into the same non-shared global can be nested, but import into the
different non-shared gloobal is not allowed while other import for non-shared
global is ongoing.
Differential Revision: https://phabricator.services.mozilla.com/D199456
In non-shared global, the sync load is performed by separate SyncModuleLoader,
with the following algorithm:
1. copy all loaded modules from async module loader, so that they can be
used in the module graph in SyncModuleLoader
2. import a module graph
3. move all modules to async module loader
ModuleLoaderBase::CopyModulesTo is for step 1, and
ModuleLoaderBase::MoveModulesTo is for step 3.
The consumer should assert that there's no fetching modules.
Differential Revision: https://phabricator.services.mozilla.com/D199455
In order to perform sync load in arbitrary global, add
ModuleLoaderBase::mOverriddenBy field, and let
ModuleLoaderBase::GetCurrentModuleLoader return the overridden loader,
so that the module loading can be overridden by SyncModuleLoader.
AutoOverrideModuleLoader manages the lifetime of the override.
Differential Revision: https://phabricator.services.mozilla.com/D199454
On the main thread, single mozJSModuleLoader instance is shared across all
loads in non-shared global, with resetting the internal state after importing
a module graph.
NonSharedGlobalSyncModuleLoaderScope manages the lifetime of each usage.
Import into the same non-shared global can be nested, but import into the
different non-shared gloobal is not allowed while other import for non-shared
global is ongoing.
Differential Revision: https://phabricator.services.mozilla.com/D199456
In non-shared global, the sync load is performed by separate SyncModuleLoader,
with the following algorithm:
1. copy all loaded modules from async module loader, so that they can be
used in the module graph in SyncModuleLoader
2. import a module graph
3. move all modules to async module loader
ModuleLoaderBase::CopyModulesTo is for step 1, and
ModuleLoaderBase::MoveModulesTo is for step 3.
The consumer should assert that there's no fetching modules.
Differential Revision: https://phabricator.services.mozilla.com/D199455
In order to perform sync load in arbitrary global, add
ModuleLoaderBase::mOverriddenBy field, and let
ModuleLoaderBase::GetCurrentModuleLoader return the overridden loader,
so that the module loading can be overridden by SyncModuleLoader.
AutoOverrideModuleLoader manages the lifetime of the override.
Differential Revision: https://phabricator.services.mozilla.com/D199454
In Gecko we use a LoadedScript pointer as the referencing private for dynamic
imports. This is passed through the JS engine as a private value, which doesn't
care what it means. Currently we store this in the module loader as a JS::Value,
but we could just as well unpack it since we know what it is. That lets use a
RefPtr which also keeps it alive and will let use remove some manual reference
counting.
We also don't need to pass it to the CreateDynamicImport method twice.
This change makes it the responsibility of the module loader for keeping the
referencing private alive until FinishDynamicModuleImport is called.
Differential Revision: https://phabricator.services.mozilla.com/D196974
According to the spec this should happen as the result of resolving a promise
(see ContinueDynamicImport). If this happens synchronously it's possible for
the importing module to still be in the evaluating state when trying to
instantiate and evaluate the dynamically imported module which breaks the
module loader invariants.
Differential Revision: https://phabricator.services.mozilla.com/D183876
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
According to the spec this should happen as the result of resolving a promise
(see ContinueDynamicImport). If this happens synchronously it's possible for
the importing module to still be in the evaluating state when trying to
instantiate and evaluate the dynamically imported module which breaks the
module loader invariants.
Differential Revision: https://phabricator.services.mozilla.com/D183876
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
According to the spec this should happen as the result of resolving a promise
(see ContinueDynamicImport). If this happens synchronously it's possible for
the importing module to still be in the evaluating state when trying to
instantiate and evaluate the dynamically imported module which breaks the
module loader invariants.
Differential Revision: https://phabricator.services.mozilla.com/D183876
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the promise with a list of module requests that are waiting for a
resource to be fetched. When the fetch completes the waiting requests are
resumed appropriately. This now happens immediately rather tha via dispatching
a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183272
Earlier, we introduced GetBaseURI to the module loader. This allows us to get the BaseURI for a
dynamic import even after the importing script/module's ScriptLoader has been cleaned up. However,
we now need to be able to handle the case where we need to run the dynamic import and load it. In
order to do this, we need to create a scriptloader configured for dynamic import. The most important
difference between this scriptloader and the one that is normally used for script loading in workers
is that we *do not have a syncLoopTarget* to which we return. There are a couple of reasons for
this:
* Dynamic import (and modules in general) relies on the event loop to resolve. If we create a
syncLoop here, we will end up pausing execution, and this breaks the StartModuleLoad algorithm. We
will never complete and the result will be that we are in the wrong state when we return here.
* We do not have perfect knowledge of the future, so we cannot keep the existing script loader alive
in the case that it might be used for loading in the future.
* We cannot migrate the ModuleLoader to not use sync loading without significantly changing other
aspects of how loading scripts on workers works. This becomes particularily evident with error
handling
(https://searchfox.org/mozilla-central/rev/00ea1649b59d5f427979e2d6ba42be96f62d6e82/dom/workers/WorkerPrivate.cpp#383-444),
and in addition, for reasons I wasn't able to discern, using the CurrentEventTarget results in hard
to identify errors. When there is time to investigate this fully, the ModuleLoader may move away
from using a syncLoop itself.
For now, all main-script loads (whether they are modules or classic scripts) will use the sync loop,
and all dynamic imports will create a new script loader for their needs that is not using the sync
loop. The book keeping for this is in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D171685
This change addresses the second issue around worker shutdown with infinitely running dynamic
imports: As the event loop is prevented from running when the worker is dying, we do not want to
delegate to the event loop in this case. This case always has a failing promise. Since this is a
failure case related to the worker dying, we stop running code, rather
than waiting for a tick (that never comes) from the event loop.
Differential Revision: https://phabricator.services.mozilla.com/D171684
This is a required change for dynamic import on workers, as the ScriptLoader is not guaranteed to
live long enough. Once the initial script loading is finished, and the script has executed, the
scriptloader is cleared and the strong reference to the workerRef is cleared so that shutdown is
possible. The workerRef is required in order to access the worker private safely. In order to
address this, we move the GetBaseURI method to the module loader itself. In the future, we should
remove the script loader interface all together.
Differential Revision: https://phabricator.services.mozilla.com/D171682
