#include "mozilla/dom/WorkerScope.h" is removed from WorkerPrivate.h, where calling WorkerPrivate::GlobalScope() without include "WorkerScope.h" makes WorkerScope as an incomplete type.
Depends on 132800
Depends on D132800
Differential Revision: https://phabricator.services.mozilla.com/D133483
Introduce a TENTATIVE state for a feature that allows the shell flags
to be used more flexibly: the feature is enabled bug --wasm-whatever
can be used as a no-op. This helps reduce breakage while we're in the
process of enabling a feature by default.
Finesse the EXPERIMENTAL state so that --no-wasm-whatever is accepted
as a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D132017
The test is in theory racy, but trying to limit the cases when it might behave badly
by running it on opt desktop builds only. Without the patch the 'period' check takes over 400ms locally and with the
patch 1-3ms.
The changes are just trying to optimize execution, not change the behavior.
Use of SuppressedMicroTasks is perhaps a bit odd, but it helps keeping
SavedMicroTaskQueue and similar code simple.
Differential Revision: https://phabricator.services.mozilla.com/D122290
This modification relies on the shared memory implemented in Bug 1698045 and on
the ability to encode and decode self-hosted content from Bug 1668361 to
optimize the JS engine initialization by making the parent process encode the
self-hosted stencil, such that all other runtime initialization would only have
to decode it, including content processes.
Differential Revision: https://phabricator.services.mozilla.com/D110578
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
The `dom::workerinternals::LoadContextOptions` must match the
`ReloadPrefsCallback` handler in order for workers to get the pref updates.
This patch add missing wasm_simd_wormhole and wasm_baselinejit options to
workers. This does change web behaviour but we always intended for the
workers to have same behaviour as main-thread for these two features.
Differential Revision: https://phabricator.services.mozilla.com/D108491
This patch makes cranelift and ion exclusive of each other: enabling
cranelift on a platform will effectively disable Ion on that platform.
Specifically there's a change at the pref/switch level that does not
go terribly deep:
- the new about:config option is javascript.options.wasm_optimizingjit,
the old wasm_cranelift and wasm_ionjit are no more
- new values of X in --wasm-compiler=X in the js shell are 'optimizing'
and 'baseline+optimizing', the old values 'cranelift', 'ion',
'baseline+ion' and 'baseline+optimizing' are still accepted but only
when ion or cranelift is available
- we keep the separate prefs internally in the code for ion and cranelift
but if ENABLE_WASM_CRANELIFT is defined then we never set the ion
pref to true, and if it is not defined then we never set the cranelift
pref to true
The trickiest changes are in testWasm.cpp and in the JIT compiler option
processing in jsapi.cpp.
People who will suffer as a result of this are those who are working
on ports of cranelift to new platforms in Firefox. As of now we have
no such work going on.
In the longer term the exclusive-or situation can be alleviated by a
switch that lets cranelift override ion when cranelift is present and
the switch is on. Patches welcome.
Differential Revision: https://phabricator.services.mozilla.com/D96059
