Cancellation happend in ParsingComplete() and Destroy() but was inconsistent in
which kinds of requests were cancelled and which were cancelled and removed.
This makes one method that cancels and removes everything and uses it in both
places.
Differential Revision: https://phabricator.services.mozilla.com/D168231
This just moves the method definitions so that they appear in roughly in the
order they are executed, to make reading and understanding this easier.
Differential Revision: https://phabricator.services.mozilla.com/D166669
This renames the following in an attempt to give consistent names to off-thread
compliation related things:
- AttemptAsyncScriptCompile -> AttemptOffThreadScriptCompile
- NotifyOffThreadScriptLoadCompletedRunnable -> OffThreadJobCompleteRunnable
- OffThreadScriptLoaderCallback -> OffThreadJobCompleteCallback
Differential Revision: https://phabricator.services.mozilla.com/D166668
The main change in this patch is to prevent access to main-thread objects
while off-thread. This is done by using nsMainThreadPtrHandle to wrap main
thread pointers in the runnable. This prevents access to their targets when
off thread and ensure they are only released on the main thread.
This means that mRunnable is now only accessed on the main thread and so it
doesn't need to be atomic and can be a normal RefPtr. We also don't need to
leak a reference to it in AttemptOffThreadScriptCompile.
This also requires that timing data is moved to the runnable.
Cancellation should always have happened by unlink or destruction of
ScriptLoadContext so handling for that is removed.
Differential Revision: https://phabricator.services.mozilla.com/D166667
This just moves the method definitions so that they appear in roughly in the
order they are executed, to make reading and understanding this easier.
Differential Revision: https://phabricator.services.mozilla.com/D166669
This renames the following in an attempt to give consistent names to off-thread
compliation related things:
- AttemptAsyncScriptCompile -> AttemptOffThreadScriptCompile
- NotifyOffThreadScriptLoadCompletedRunnable -> OffThreadJobCompleteRunnable
- OffThreadScriptLoaderCallback -> OffThreadJobCompleteCallback
Differential Revision: https://phabricator.services.mozilla.com/D166668
The main change in this patch is to prevent access to main-thread objects
while off-thread. This is done by using nsMainThreadPtrHandle to wrap main
thread pointers in the runnable. This prevents access to their targets when
off thread and ensure they are only released on the main thread.
This means that mRunnable is now only accessed on the main thread and so it
doesn't need to be atomic and can be a normal RefPtr. We also don't need to
leak a reference to it in AttemptOffThreadScriptCompile.
This also requires that timing data is moved to the runnable.
Cancellation should always have happened by unlink or destruction of
ScriptLoadContext so handling for that is removed.
Differential Revision: https://phabricator.services.mozilla.com/D166667
Note that modules can't be specified in Link preloads with `rel=preload`,
only in `rel=modulepreload`. We currently only support `rel=preload` in
early hints. See Bug 1798319 for updates on module preloads.
Differential Revision: https://phabricator.services.mozilla.com/D161175
Note that modules can't be specified in Link preloads with `rel=preload`,
only in `rel=modulepreload`. We currently only support `rel=preload` in
early hints. See Bug 1798319 for updates on module preloads.
Differential Revision: https://phabricator.services.mozilla.com/D161175
The problem is that synchronous XMLHttpRequest requests can spin the event loop
and cause us to process dynamic module loads (by calling
JS::FinishDynamicModuleImport) when we are already inside JS::ModuleEvaluate.
The module algorithms assume that they are not reentrant.
The patch changes dyammic module load processing to happen in the same way as
async script loads (of both classic scripts and modules), which are blocked
during sync XHR by Document::SuppressEventHandling calling
ScriptLoader::AddExecuteBlocker.
Differential Revision: https://phabricator.services.mozilla.com/D157218
This patch move the ShouldApplyDelazificationStartegy as well as the
ApplyDelazificationStrategy under FillCompileOptionsForRequest.
As not all delazification strategies are capable of handling modules yet (Bug
1760334), and do not apply to cached-stencil, we have to add extra filters to
prevent ShouldApplyDelazificationStrategy to access custom delazification mode.
Differential Revision: https://phabricator.services.mozilla.com/D150118
This patch move the ShouldApplyDelazificationStartegy as well as the
ApplyDelazificationStrategy under FillCompileOptionsForRequest.
As not all delazification strategies are capable of handling modules yet (Bug
1760334), and do not apply to cached-stencil, we have to add extra filters to
prevent ShouldApplyDelazificationStrategy to access custom delazification mode.
Differential Revision: https://phabricator.services.mozilla.com/D150118
This patch adds a new off-thread delazification strategy, which adds a bit of
overhead to queue function with a priority order, which put the largest function
as the first functions to be delazified.
The intent of this new strategy is to limit the usage of main-thread
delazification to the smallest function, in case where the main-thread would win
the delazification race.
Differential Revision: https://phabricator.services.mozilla.com/D149651
This leaves the code in ScriptLoader and ScriptLoadHandler a lot more readable.
ScriptBytecodeCompressedDataLayout and ScriptBytecodeDataLayout simplify
locating data in the ScriptLoadRequest bytecode buffer when compressing and
decompressing it.
The interface is still error-prone. For example, these classes don't check
that the returned pointers are within the bounds of the buffer.
Differential Revision: https://phabricator.services.mozilla.com/D145011
The SRI hash at the beginning of ScriptLoadRequest::mScriptBytecode is left
uncompressed because ScriptLoader::OnIncrementalData() tries to decode it
as soon as enough data is read (instead of waiting until OnStreamComplete()).
ScriptLoader writes the length of the uncompressed bytecode to the buffer
to make it easy for ScriptLoadHandler to allocate an buffer of the right size
to decompress the bytecode.
These changes are based on the bytecode compression implemented for WASM in
dom/fetch/FetchUtil.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D141524
