This reverts commit b10b7c8add.
Revert "Bug 1991081 - Part 6: Remove testing-only events from EncodeBytecodeAndSave. r=nbp"
This reverts commit caf275708e.
Revert "Bug 1991081 - Part 5: Use single field for SRI and optional bytecode, for bytecode case and for cached stencil case. r=nbp"
This reverts commit 86631a6e10.
Revert "Bug 1991081 - Part 4: Use LoadedScript for logging in EncodeBytecodeAndSave. r=nbp"
This reverts commit 0f9d7f11e8.
Revert "Bug 1991081 - Part 3: Store nsICacheInfoChannel to LoadedScript also in text and bytecode variants. r=nbp"
This reverts commit 370f5bcd48.
Revert "Bug 1991081 - Part 2: Store stencil to LoadedScript also in text and bytecode variants. r=nbp"
This reverts commit 7eaf4f425f.
Revert "Bug 1991081 - Part 1: Rename Stencil variant to CachedStencil in LoadedScript. r=nbp"
This reverts commit a7a6ce8f6f.
Most changes are automated. Relevant bit is dom/.clang-format. I had to
manually disable clang-format in a few places where importing external
files and so on that aren't self-contained, and fix a couple includes /
forward declarations.
Differential Revision: https://phabricator.services.mozilla.com/D256800
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
Now that the Worker ScriptLoader largely conforms to the same shape as the DOM ScriptLoader, and
represents requests in the same way, we can start sharing some code. The ScriptLoadHandler isn't
entirely common to both cases, as it handles preloads (which are not possible in workers). This
patch splits out the common class, ScriptDecoder, as it's own thing. A demonstration of its use is
in Part 8 of this patch queue.
Differential Revision: https://phabricator.services.mozilla.com/D146213
This patch splits out the decoding from the ScriptLoadHandler. This will be reused by the worker
ScriptLoader for loading scripts via both NetworkLoadHandler and CacheLoadHandler.
Differential Revision: https://phabricator.services.mozilla.com/D146178
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
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 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
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
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
Tooru Fujisawa