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
Adds a delazification mode, which spawn a concurrent depth-first delazification
of all function to fill the stencil cache, to later compare cached results with
stencils produced by on-demand delazification.
The delazification mode also works when being used from a main-thread top-level
compilation, in which case the delazification tasks are created and potentially
blocking the main thread, while the delazification is happening.
This way of doing help comparing on-demand delazification, based on instantiated
stencils with concurrent delazification, based on stencils. Which is a good
mode for fuzzing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D145992
Adds a delazification mode, which spawn a concurrent depth-first delazification
of all function to fill the stencil cache, to later compare cached results with
stencils produced by on-demand delazification.
The delazification mode also works when being used from a main-thread top-level
compilation, in which case the delazification tasks are created and potentially
blocking the main thread, while the delazification is happening.
This way of doing help comparing on-demand delazification, based on instantiated
stencils with concurrent delazification, based on stencils. Which is a good
mode for fuzzing purposes.
Differential Revision: https://phabricator.services.mozilla.com/D145992
Module imports can be cyclic so it's more correct to refer to them as graphs.
The spec also uses this term.
Depends on D144599
Differential Revision: https://phabricator.services.mozilla.com/D144600
This renames the method to correspond to StartFetch and adds a status argument
so clients can call this rather than
SetModuleFetchFinishedAndResumeWaitingRequests on error.
Depends on D144595
Differential Revision: https://phabricator.services.mozilla.com/D144596
There are a few places where we call one of two overloads of a fuction based on
the contents of a MaybeOneOf. We can simplify this code by giving the class a
map method.
Differential Revision: https://phabricator.services.mozilla.com/D144595
This removes the global object field from the script load context and gets the
global from the script loader / module loader where necessary.
Differential Revision: https://phabricator.services.mozilla.com/D142833
This gives the module loader a field for the current global, since a module map
is only associated with a single global.
This adds a method to Document to tell the script loader when its global
changes. I'm not sure of when we do this exactly.
Differential Revision: https://phabricator.services.mozilla.com/D142831
The script loader will need to deal with requests from more than one module
loader so this adds methods to the request which dispatch to the correct
loader.
Differential Revision: https://phabricator.services.mozilla.com/D142828
StartModuleLoadImpl moves to the base class and uses to new virtual methods
CanStartLoad and StartFetch which are implemented by the derived class.
Differential Revision: https://phabricator.services.mozilla.com/D141736
This is used when we explicitly don't want to load cached bytecode. It is
better served by a separate flag in the request than a state.
Differential Revision: https://phabricator.services.mozilla.com/D142042
This also renames 'loading' enum values to 'fetching' since this is more
specific. Loading covers the whole process of loading, which includes the other
states.
Enum values have the leading 'e' removed in line with the coding style for enum
classes.
Differential Revision: https://phabricator.services.mozilla.com/D142041
This removes the microtask checkpoint when instantiating modules and moves the
one when creating a module script to the the script loader.
Differential Revision: https://phabricator.services.mozilla.com/D141252
After enabling bytecode cache for module script, we need to handle
the SRI mismatch on bytecode cache, that requires reloading the script source
again.
Differential Revision: https://phabricator.services.mozilla.com/D140551
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
After enabling bytecode cache for module script, we need to handle
the SRI mismatch on bytecode cache, that requires reloading the script source
again.
Differential Revision: https://phabricator.services.mozilla.com/D140551
The module scripts are scanned immediately before executing, and if the
module script is not yet executed, and it matches the requirement for encoding
(size, fetch count, etc), it's marked as encode,
and they're scanned again immediately after executing, and marked scripts are
queued for bytecode encoding.
This patch doesn't actually enable the encoding, given ShouldCacheBytecode
returns false because the caching is not enabled for the channel and
GetCacheTokenFetchCount fails.
Differential Revision: https://phabricator.services.mozilla.com/D140296
As a preparation to use the bytecode encoding in the module evaluation code,
ScriptLoader::MaybePrepareForBytecodeEncoding is split into 2 parts:
* one for performing preparation before executing script
* one for queuing the request for bytecode encoding after executing script
In module's case, the bytecode encoding handling must be done on the entire
import tree, and also the module object's ScriptSlot is cleared on execution.
So, the script reference must be copied to the corresponding script load request
field before execution, and the script source must be queued for bytecode
encoding after executing the top-level script, so that incremental encoding
reflects functions called there.
Differential Revision: https://phabricator.services.mozilla.com/D140295
Module bytecode should use different MIME type, to avoid mixing up script/module
bytecodes for single JS file.
This patch adds a static method that simply returns the current bytecode MIME
type.
The later patch adds a new MIME type for module bytecode and modify the
ScriptLoader::BytecodeMimeTypeFor method to return corresponding MIME type.
Differential Revision: https://phabricator.services.mozilla.com/D140292
mScript field is used only for bytecode encoding, and this field is used as a
flag for whether the script load request has bytecode-encoding-related
references.
Differential Revision: https://phabricator.services.mozilla.com/D140288
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
This patch changes the way we parse JavaScript coming from Necko while loading
web pages, by adding an about:config flag named
javascript.options.delazification.strategy which is used to select between:
0 - On Demand
1 - Concurrent Depth First
255 - Parse Everything Eagerly
Previously, we moved from On-demand delazification, to parsing everything
eagerly to improve responsiveness of the browser, but we knew that more room for
optimization exists.
This toogle is meant to explore the space of delazification strategies, such
that we can parse functions of JavaScript files on an helper thread, while the
JavaScript file is being executed on the main thread. The space of
delazification strategies goes from ordering the order in which functions are
processed, as well as filtering functions which are processed. Not all functions
have to be delazified, and if the main thread needs a function which is not
parsed yet, it will fallback to parsing it on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D138034
The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
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
The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
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
The goal of splitting classic script loading from module script loading was to keep a minimum
selection of methods for other script loaders to implement. In addition, the security
flags were distinct for the two cases, and had no overlap.
Caching behavior was left as shared, as it is likely modules will have this soon.
Differential Revision: https://phabricator.services.mozilla.com/D132605
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
