It's suspected that this may induce performance regressions. Do it
anyway, just to find out how bad it is. (But only on Nightly, for now.)
For simplicity's sake, this does not include any additional telemetry;
the decision of whether and what any additional telemetry is needed will
be deferred until we have some feedback from what we've already got.
Differential Revision: https://phabricator.services.mozilla.com/D155301
This patch includes:
- changes to WebRequest.jsm to always default to only merge the CSP headers returned by MV3 extensions
- changes to the test_ext_webRequest_mergecsp.js xpcshell test to cover the behavior expected
with MV3 extensions and combinations of both MV2 and MV3 extensions changing CSP headers
for the same intercepted web request.
For MV3 extensions we would prefer a more explicit and predictable way for the
extensions to be allowed to replace the CSP header, instead of keeping the same
unpredictable and implicit one that we currently support for MV2 extensions.
Differential Revision: https://phabricator.services.mozilla.com/D154983
* Only show the mobile promo when tab syncing is enabled
* Toggle the promo & confirmation visibility in all setup states to ensure it gets hidden when we re-enter the sign-in to FxA state
* Add test coverage for signing out
Differential Revision: https://phabricator.services.mozilla.com/D154850
This allows to scalar replace the `MNewCallObject` in cases like:
```js
function f() {
var r = 0;
for (var i = 0; i < 100; ++i) {
var fn = i => () => i;
r += fn(i)();
}
return r;
}
```
This code is compiled to:
```
48 lambda newcallobject43:Object constant47:Object
53 guardtofunction lambda48:Object
54 guardfunctionscript guardtofunction53:Object
57 functionenvironment guardfunctionscript54:Object
```
`MGuardToFunction` and `MGuardFunctionScript` weren't present in Ion when scalar
replacement support for `MNewCallObject` was originally implemented. For Warp
we need to handle those two instructions, too.
There aren't any new tests, because `MNewCallObject` is an implementation detail
and can't be tested from JS. (The `MLambda` is already scalar replaced without
this change.)
Differential Revision: https://phabricator.services.mozilla.com/D155470
When generating bytecode, we are looking for names locations, using
`ScopeContext::searchInEnclosingScope`, to replace them by integers, which
improve the speed of the generated code.
However, looking for these names can it-self be extremlly costly if there is a
scope with a very large number of bindings. Multiple attempts have been made in
the past to improve this situation by caching bindings within the scope of each
compilation. Unfortunately, this was either a regression or a non-improvement,
as these lookups might be done by thousands of inner functions.
This patch adds content to the `ScopeBindingCache`, introduced in the previous
patch as placeholder. The `ScopeBindingCache` is a cache which persists across
multiple compilations. Therefore, if a scope chain is shared by multiple
delazified inner function, the caching cost would be mutualized.
The `ScopeBindingCache`, as the `searchInEnclosingScope` function have to deal
with 2 different kind of scopes. Either we are manipulating stencils, in case of
concurrent delazification, or we are manipulating GC objects, in case of
on-demand delazification. Thus the interface provide overloaded functions to be
able to write generic code, and contains 2 `ScopeBindingMap`, one for each type
of atoms `TaggedParserAtomIndex` and `JSAtom*` respectively coming from scope
`*::ParserData` and `*::RuntimeData` of each scope.
The `ScopeBindingMap` is a `HashMap` indexed on the `AbstactBaseScopeData` for
each Atom type. It maps the scope data, i-e the pointer to the array of
bindings, to the `BindingMap`.
The `BindingMap` provides a `HashMap` and a `catchAll` field. The `HashMap` is
used to map each binding to its `NameLocation`, while the `catchAll` is used to
handle the case where the scope is used to collect all new names, when
dynamically created.
The `BindingMap`'s `hashMap` makes use of the lookup capability of `HashTable`
in order to avoid storing the context of each atom next to each key. As all
bindings are coming from the same scope data. Thus the `Lookup` provides the
context to interpret the keys which are stored in the `hashMap`. This `HashMap`
also feature the ability to compare all 3 different atoms possible. The
comparisons between these 3 different atoms is handled by the `GenericAtom`
class.
The `GenericAtom` class provides a uniform interface for comparing the 3
different type of atoms against each others, such that atoms can be registered
in the `BindingMap` with one type, while being look up with the same or
different type. The `GenericAtom` exposes a `hash` field, which is consistent
across all atoms types, as well as an equality operator. The 3 different atoms
types are: `TaggedParserAtomIndex` provided by the `ScopeStencilRef`, the
`TaggedParserAtomIndex` provided by the `ParserAtomTable` and the `JSAtom*` from
GC objects.
Differential Revision: https://phabricator.services.mozilla.com/D154514
This patch isolate the boiler plate code to create a dummy ScopeBindingCache
with no logic to split the noise of this not-so mechanical patch driven by
compiler error messages.
This patch modify the interface of every function, adding the option to provide
a custom ScopeBindingCache when parsing a Stencil, except for publicly facing
functions such as from `js/public/experimental/JSStencil.h`.
The intent being that Helper thread functions, which are relying on Stencil
should have their own ScopeBindingCache which is either unused, or dedicated to
caching the bindings of multiple delazifications. The reasons are that in the
future we are interested in stripping the JSContext* out of HelperThreads, and
that there is no value in sharing the content across threads.
Differential Revision: https://phabricator.services.mozilla.com/D154513
The next patch is creating a cache which is capable of looking up different kind
of string types. However, each string type need some contextual information to
be able to compare them against each others, which adds complexity to the lookup
type. In addition, the keys are of only one string type, and therefore we try to
avoid storing this context as part of each key, but instead provide it with the
contextual information coming with the Lookup type.
Therefore, when we want to insert a key, which might already be present, using
`put`. We have to provide a `aLookup` argument which knows how to compare keys.
This also make the interface similar to `putNew` which already has the
distinctions between the `Lookup` argument and the `KeyInput` argument.
Differential Revision: https://phabricator.services.mozilla.com/D154512
This patch adds 2 short-circuits to improve the lookup of bindings in the
enclosing scope chain, during on-demand delazification.
The first short-circuit is in Function scope, by comparing bindings against each
others, we can compare either `JSAtom` directly against `JSAtom` or
`TaggedParserAtomIndex` directly with `TaggedParserAtomIndex` from the
CompilationStencil context.
The second short-circuit is in `InputName::isEqualTo`, in the case where we are
comparing a `JSAtom` against the `TaggedParserAtomIndex` from the compiled
script, we can query the hash of both and compare them before converting the
`TaggedParserAtomIndex` into a `JSAtom`, which should make the comparison
faster.
Differential Revision: https://phabricator.services.mozilla.com/D154511
This patch moves the hops offseting out of the `searchInEnclosingScope`
computation such that `searchInEnclosingScope` computation can provide a result
which is independent from where the named is looked for. Making the NameLocation
independent enables us to later cache the NameLocation.
Differential Revision: https://phabricator.services.mozilla.com/D154510
Since mozglue is now aware of Gecko process-types, remove the
configurator for this bug's associated experiment. Instead, use
`GeckoProcessType` directly in mozjemalloc.
This requires a couple of adjustments for non-Firefox uses of
mozjemalloc:
- Since `logalloc-replay` uses mozjemalloc in an odd way, tweak its
`moz.build` to also include `mozglue/misc/ProcessType.cpp`.
- Since `GeckoProcessType` is not available in standalone SpiderMonkey
builds, make the mostly-arbitrarily choice to always stall there.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D155300
This patch stops removing sources based on the `source.thread` property,
instead this should based of the source actors thread. This enables us to remove
the `source.thread` property which would be wrong when the breakpoints per url
work D150628 is done.
Differential Revision: https://phabricator.services.mozilla.com/D154904
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
These are gated by the same layout.css.font-tech.enabled pref as the
closely-related `tech()` function for the @font-face src descriptor;
once the spec questions are settled, we should enable them all together.
Differential Revision: https://phabricator.services.mozilla.com/D155359
The glyphs "b" and "c" here have radial gradients with non-[0..1] color stop ranges,
and are compared against versions with equivalent normalized gradients.
Depends on D155080
Differential Revision: https://phabricator.services.mozilla.com/D155472
- Remove script_shift_attributes preference and related test, warning
message and parsing.
- Do not remove subscriptshift/supscripshift atoms, since they are
still needed for nsTreeSanitizer.
Differential Revision: https://phabricator.services.mozilla.com/D154195
