The features rewrite got the names of the Firefox wasm prefs wrong, they
all have a wasm_ prefix that got chopped off. This puts it back.
It sucks that we don't have meaningful test cases for this. A manual
test case (see bug) is easy, but how to automate it?
Differential Revision: https://phabricator.services.mozilla.com/D112325
This patch enables Ion by default as the optimising compiler for wasm on
AArch64, and disables Cranelift. Cranelift is still available if the build is
configured with --enable-cranelift. In that case, *only* Cranelift is
available. There are no configuration flags to enable both Ion and Cranelift
simultaneously.
This mostly reverts the Phase 0 and Phase 1 patches that are bug 1678097
D102420 and D101867 respectively.
The command line option --wasm-force-ion has been removed.
With this patch in place, users of the shell should specify
`--wasm-compiler=optimizing` to get an optimising wasm compiler. Which one is
provided depends on the configuration options as described above.
`--wasm-compiler=cranelift` and `--wasm-compiler=ion` are now only accepted
when the relevant compiler has been enabled, and so neither is a "safe" way to
request an optimising tier.
For that reason, test directories that previously requested
also-with-Ion-please by stating `test-also=--wasm-compiler=ion;` in their
`directives.txt` file, have been changed to use
`test-also=--wasm-compiler=optimizing;`.
In places where the JSContextOptions are set, the non-selected compiler (Ion
or CL) is explicitly set to `false` (eg, `.setWasmIon(false)`). This may be
overly conservative, but seems wise given that it's not immediately obvious
what the previous value of that flag is, and given the recent difficulties
with incorrect option propagation/handling (eg, bug 1697560).
Differential Revision: https://phabricator.services.mozilla.com/D101695
This patch enables Ion by default as the optimising compiler for wasm on
AArch64, and disables Cranelift. Cranelift is still available if the build is
configured with --enable-cranelift. In that case, *only* Cranelift is
available. There are no configuration flags to enable both Ion and Cranelift
simultaneously.
This mostly reverts the Phase 0 and Phase 1 patches that are bug 1678097
D102420 and D101867 respectively.
The command line option --wasm-force-ion has been removed.
With this patch in place, users of the shell should specify
`--wasm-compiler=optimizing` to get an optimising wasm compiler. Which one is
provided depends on the configuration options as described above.
`--wasm-compiler=cranelift` and `--wasm-compiler=ion` are now only accepted
when the relevant compiler has been enabled, and so neither is a "safe" way to
request an optimising tier.
For that reason, test directories that previously requested
also-with-Ion-please by stating `test-also=--wasm-compiler=ion;` in their
`directives.txt` file, have been changed to use
`test-also=--wasm-compiler=optimizing;`.
In places where the JSContextOptions are set, the non-selected compiler (Ion
or CL) is explicitly set to `false` (eg, `.setWasmIon(false)`). This may be
overly conservative, but seems wise given that it's not immediately obvious
what the previous value of that flag is, and given the recent difficulties
with incorrect option propagation/handling (eg, bug 1697560).
Differential Revision: https://phabricator.services.mozilla.com/D101695
We also call setHelperThreadTaskCallback earlier, now it's done in
XPCJSContext::Initialize. So GlobalHelperThreadState could know earlier
if we're dispatching to a external thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D110924
This commit adds a declarative `JS_FOR_WASM_FEATURES` macro which
expands for every WebAssembly proposal we are gating. Most feature
gating code is refactored to use this macro so that we have one place
we need to change to get the majority of this code working. The only
place that needs to be updated for new features is the browser pref
declaration code, as that cannot use this macro. This is documented
in the new WasmFeatures.h header.
The feature gating logic should work almost identically as before.
The changes are:
* All browser prefs are moved to StaticPrefList.yaml
* The code to enable a feature was conditionally compiled to not
enable the feature at variously stages of the "flag-flow". Now
the only place that is conditionally compiled to not work is
in the WasmXFlag functions. This is to make the macro simpler
and might be able to be reverted if need be.
* The flag for gc is shortened from gcTypes to gc so that the
existing usages of the wasmGcEnabled shell function don't have
to change.
This commit also has the effect of giving function-references/gc/
exception-handling a proper browser pref for enabling the features.
Differential Revision: https://phabricator.services.mozilla.com/D110820
This never actually worked, because nothing ever listened to the notification
sent in XPCJSContext (kill-content-script-sandbox). We're also removing the
"Temporarily disable extension" button in the slow addon notification, which
was the primary caller of this - however, that's in a separate patch.
Differential Revision: https://phabricator.services.mozilla.com/D110583
GetterOp/SetterOp are now only used internally for array and arguments objects.
PropertyDescriptor no longer has to know about these properties.
Differential Revision: https://phabricator.services.mozilla.com/D109358
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
Firstly we need to find a usable ScriptLoader for code in the content script sandbox,
for that we use the normal ScriptLoader associated with DOMWindow wrapped by the sandbox.
Secondly we need to execute the module in the global of the sandbox instead of the
"ScriptGlobal" the ScriptLoader is actually associated with. The main
behavior change here comes from using xpc::NativeGlobal in HostImportModuleDynamically
and passing that global around inside ScriptFetchOptions.
To ensure that content-scripts and the webpage don't share imported modules,
the module map (mFetchingModules and mFetchedModules) now uses a complex key
of <URI, Global>. The Global is a nullptr for normal imports from a webpage.
Differential Revision: https://phabricator.services.mozilla.com/D107076
In Phase 1, both Ion and Cranelift are available, and the default is switched
to Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to
select Ion, or make sure javascript.options.wasm_force_ion is true in
about:config. Phase 1 is appropriate for fuzzing, after the patch set lands
in mozilla-central but before Ion is enabled by default. The patch for Phase
1 will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
Differential Revision: https://phabricator.services.mozilla.com/D101867
In Phase 0, both Cranelift and Ion are available on arm64, and Ion is the
default. Use --wasm-force-cranelift or --wasm-compiler=cranelift at the shell
to select Cranelift, or set javascript.options.wasm_force_ion to false in
about:config. Phase 0 is appropriate for developers, before the patch set
lands in mozilla-central and before SIMD is present.
In Phase 1, both compilers are still available, but the default is switched to
Cranelift. Use --wasm-force-ion or --wasm-compiler=ion at the shell to select
Ion, or make sure javascript.options.wasm_force_ion is true in about:config.
Phase 1 is appropriate for fuzzing, after the patch set lands in
mozilla-central but before Ion is enabled by default. The patch for Phase 1
will appear on bug 1678097 and will be very small, and MUST land with the
patch for Phase 0.
In Phase 0 and Phase 1, --wasm-compiler=cranelift and --wasm-compiler=ion are
both accepted, and do the expected thing.
In Phase 2, Cranelift becomes disabled in moz.configure and all the changes in
the present patch are removed again. The patch for Phase 2 will appear on bug
1686626 and will revert Phase 0 and Phase 1, and additionally update
moz.configure.
Differential Revision: https://phabricator.services.mozilla.com/D102420
To simplify this code, turns these prefs into unlisted prefs on MIPS
platforms since the JIT support is missing there. The JitOptions will
continue to default them to false on MIPS.
Differential Revision: https://phabricator.services.mozilla.com/D108107
