In contrast to other fields, mBaseURL is not populated in the constructors.
Thus we just need to remove the ScriptLoadRequest::mBaseURL field and
use the LoadedScript::mBaseURL instead.
Differential Revision: https://phabricator.services.mozilla.com/D267360
ScriptLoadRequest::mKind == eImportMap case has been using
LoadedScript::mKind == eClassic.
This patch solves this inconsistency by introducing another subclass.
Differential Revision: https://phabricator.services.mozilla.com/D267353
In contrast to other fields, mBaseURL is not populated in the constructors.
Thus we just need to remove the ScriptLoadRequest::mBaseURL field and
use the LoadedScript::mBaseURL instead.
Differential Revision: https://phabricator.services.mozilla.com/D267360
ScriptLoadRequest::mKind == eImportMap case has been using
LoadedScript::mKind == eClassic.
This patch solves this inconsistency by introducing another subclass.
Differential Revision: https://phabricator.services.mozilla.com/D267353
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.
In order to store ModuleScript in SharedScriptCache, we need to strip off
all GC-things and runtime-related flags.
All fields in ModuleScript matches either of them, so just converting to
base class LoadedScript fits this purpose.
Differential Revision: https://phabricator.services.mozilla.com/D242305
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
This change adds the `LoadedScript` in the memory reporter.
This change is needed as we are looking into using the `LoadedScript` as a value
of the `SharedSubResourceCache`. The upcoming cache requires the Value to be
registered in the memory reporter, providing a `SizeOfInlcudingThis` function.
Differential Revision: https://phabricator.services.mozilla.com/D203132
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
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/D197921
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
Tooru Fujisawa