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
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
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
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
