The Scriptloader will be shared by multiple modules, not all of them have ready access to the
docshell (MozJSComponentLoader currently uses the JSContext for this purpose. Workers and worklets
are not tracking performance yet). Our profiling code relies on the docShell present in the script loader. This changes the
current profiling code to use the JSContext instead.
Differential Revision: https://phabricator.services.mozilla.com/D132604
Changed all off-thread tasks not to use parse global.
Removed bug-1138390.js because off-thread script decode no longer wait for GC.
* ParseTask::parseGlobal is removed in Part 2
* OffThreadParsingMustWaitForGC is removed in Part 3
* GlobalHelperThreadState::parseWaitingOnGC is removed in Part 3
* GlobalHelperThreadState::generateLCovSources is removed in Part 5
* ParseTask::scripts is removed in Part 6
* ModuleObject::fixEnvironmentsAfterRealmMerge is removed in Part 7
* Zone::{setCreatedForHelperThread,clearUsedByHelperThread} are removed in
bug 538450
* RealmCreationOptions::setMergeable is removed in bug 1655768
* MergeRealms is removed in bug 1655768
Differential Revision: https://phabricator.services.mozilla.com/D131354
When a preload request is used, it might be being compiled off-thread.
Currently this is handled for defer and async requests in AddDeferRequest and
AddAsyncRequest but not for XSLT or other kinds of requests. The patch handles
this whenever we use a preload request.
I don't know for sure that this is what's causing the crash but it seems likely
given the assertion.
Depends on D120072
Differential Revision: https://phabricator.services.mozilla.com/D120073
When a preload request is used, it might be being compiled off-thread.
Currently this is handled for defer and async requests in AddDeferRequest and
AddAsyncRequest but not for XSLT or other kinds of requests. The patch handles
this whenever we use a preload request.
I don't know for sure that this is what's causing the crash but it seems likely
given the assertion.
Depends on D120072
Differential Revision: https://phabricator.services.mozilla.com/D120073
The original patch had caused some assertions so I rewrote it. This now puts
all untracked top-level requests on the new list while they are being compiled
so handles preload requests too.
Differential Revision: https://phabricator.services.mozilla.com/D119386
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
There are parse tasks present when the JS engine is being shut down that have
finished but haven't had their results collected by the embedding. This
shouldn't happen, and I think it's happening here because we're leaking a
JSRuntime (we cancel these when we shut down a runtime).
There's a comment that says this isn't necessary but cancelling outstanding
compile requests in ScriptLoader::Destroy fixes this problem on try. I don't
understand well enough to know what's going wrong with the current approach but
this fixes both the crash and the leak.
Differential Revision: https://phabricator.services.mozilla.com/D119315
Replace JS pageload proportion probes with absolute time measurements and add new probes to measure GC and main thread parsing impact during page load.
Differential Revision: https://phabricator.services.mozilla.com/D114388
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
