Also cancel module load requests when cancelling requests generally.
What was happening here was that a previous load was completing and calling
into the wrong module loader, because the loader to use is determined via the
current global, and this was now associated with a different document / script
loader / module loader.
Differential Revision: https://phabricator.services.mozilla.com/D179787
This patch allows us to reject any outstanding requests when terminating a worker. As this is
controlled by the module loader, the approach I took here was to reject the promises and allow the
moduleloader to
shutdown. I am open to alternatives however.
Differential Revision: https://phabricator.services.mozilla.com/D173290
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
When running an infinitely-looping dynamic import, it is possible for the module loader to still be
holding on to that module at shutdown. Shutdown on the worker means that we will no longer run the
event loop, which will execute the dynamic import promises necessary to clear the global. The result
is that the global is kept alive. By calling `Shutdown()` we prevent this partially. We additionally
need to address the failure in the module code (next patch).
Differential Revision: https://phabricator.services.mozilla.com/D171683
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
We should check for previous cancellation on all path where a module load
request's state can be changed by an asynchronous action. Also add assertions
about the expected previous state where possible.
Differential Revision: https://phabricator.services.mozilla.com/D168233
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
Original patch by mccr8.
At least for the cycle collector, the purpose of calling unmark gray when
accessing a JS field of a C++ object is to avoid creating references from a
black object to a gray object. However, this particular code is writing
undefined, so that should not be a danger.
This particular code is by its nature dealing with GC things that are gray and
may be about to be GCed, so calling unmark grey can waste a tremendous amount
of time. On a profile of collecting a JS-heavy page, I was seeing 20% of the
100ms CC being spent on it.
The patch uses unbarrieredGet in ModuleScript::UnlinkModuleRecord and adds a
new API to clear a module record's private value without checking whether
associated objects are gray.
Differential Revision: https://phabricator.services.mozilla.com/D165202
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
Not related to the rest of the bug. This is a simplification so that we set the
supported import assertions once rather than querying the host every time they
are needed.
Differential Revision: https://phabricator.services.mozilla.com/D164914
As of the prior patch, these are no longer needed. I removed
these with a script, then ran clang-format on the files, then
manually reverted a few unrelated changed from the formatter.
Differential Revision: https://phabricator.services.mozilla.com/D164829
This is a slightly annoying thing that can happen. When we abruptly cancel (such as an infinitely
running script being forcibly terminated) we will be in a state where the EvaluateModule call will
finish _after_ the loader is destroyed. So, instead we track if there has been a forcible
cancelation, and exit early.
Depends on D155690
Differential Revision: https://phabricator.services.mozilla.com/D155568
This implements a method to initialize the moduleLoader for workers. This will initialize only once, for all worker types (module and classic).
Depends on D147324
Differential Revision: https://phabricator.services.mozilla.com/D147326
This is more complicated because it needed a change to the public API now we're
not longer returning an array object. The new API is less error prone since
it's no longer possible for the caller to mutate the object returned.
Depends on D163948
Differential Revision: https://phabricator.services.mozilla.com/D163949
I've looked at this for a while and still don't know how this can happen but it
does seem reasonable to add a check here that we haven't already completed the
request.
Depends on D162386
Differential Revision: https://phabricator.services.mozilla.com/D162387
We're getting a bunch of crashes related to initializing AutoJSAPI from a
JSObject pointer that turns out to be null. That overload of Init() gets the
native global from the JSObject and since we already have a native global in
the module loader we can use the overload that takes that instead. This
overload does a null check so we will catch the case where the global is null
(although that should also not happen).
This might just move crashes elsewhere but it's a reasonable tidyup.
Differential Revision: https://phabricator.services.mozilla.com/D162386
I was over eager in introducing the strong pointers to WorkerLoadContext. It turns out that
previously when we were cycle collecting our ScriptLoadRequests, we were also cleaning up everything
related to WorkerLoadContext. Also, in an attempt to fix the cancellation for workers, We
accidentally stopped cleaning up the reference to the cache creator. This patch does the following:
1) cleans up the cache creator reference whenever we finish with a cache load handler. This is done
by calling Fail appropriately. This solves both bug 1798667 (we no longer reach NEW_URI if we fail)
and 1781295 (we no longer leak memory because things were not cleaned up properly).
2) Does no remove the back reference to WorkerLoadContext from the LoadRequest. It turns out that
this is sometimes necessary. There is a chance that we will accidently try to access the
WorkerLoadContext after cancellation. This actually causes problems later on in the module code.
Differential Revision: https://phabricator.services.mozilla.com/D161288
As WorkerLoadContexts now inherit from a non-CC'd loadContextBase, we have two outcomes.
1) we need to break cycles with ScriptLoadRequests manually, so that ScriptLoadRequests can be collected (ScriptLoadRequests must be CC'd).
2) we can now have refptrs to WorkerLoadContexts in the CacheLoadHandler and NetworkLoadHandler classes, and remove any remaining raw pointers to ScriptLoadRequest/WorkerLoadContext. There are cases where the NetworkLoadHandler or CacheLoadHandler might outlive the Worker Loader, so having refpointers here should help us recover in those cases.
Differential Revision: https://phabricator.services.mozilla.com/D160334
In order to use the WorkerLoadContext as a handle for ScriptLoadRequests in the main thread portion
of worker loading, we need to make it thread safe. Which means, it cannot be CC'd, and we need to
manually break cycles. This patch does the first portion of this work, which is inroduce two new
loadContextBase classes, that are either cc'd or not cc'd. For the DOM and mozJSComponent loader, we
continue to use a CC'd LoadContextBase. Workers however now have a non-cc'd variant.
Differential Revision: https://phabricator.services.mozilla.com/D160333
It would be nice to assume this but CompileFetchedModule can potentially fail for reasons that
are not JS-related.
Also check for the exception being |undefined| which would cause
ModuleScript::HasParseError to return false. Such an exception should never be
thrown by parsing but check for it just in case.
Add a diagnostic assert to check module script state is as we expect to
hopefully catch related problems sooner.
Differential Revision: https://phabricator.services.mozilla.com/D160788
I don't know whether this is the problem, but if we try and cancel a request
that has already been cancelled it would produce this crash.
Differential Revision: https://phabricator.services.mozilla.com/D159167
