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
The issue here is that we access the WorkerPrivate::mJSContext while dispatching
a micro task runnable to micro task queue. While we are running the worker
script, this should be safe. However, it's possible that process the micro tasks
while clearing the main event queue. And, in this case, the worker is about to
shutdown so the mJSContext has already set to a nullptr.
GetCurrentWorkerThreadJSContext() returns WorkerPrivete::mJSContext. It's set at
the beginning of the WorkerPrivate::DoRunLoop() (which is got from
CycleCollectedJSContext::mJSContext), and it is set to a nullptr at the end of
WorkerPrivate::DoRunLoop(). Thus, the result of
CycleCollectedJSContext::Context() is the same as the result of
GetCurrentWorkerThreadJSContext() before either of the JSContext pointer is set
to a nullptr. So, we should be safe to change the use of the getter function to
Context() here.
Differential Revision: https://phabricator.services.mozilla.com/D87615
- Using MonitorAutoLock/Monitor::Wait with the timeout argument instead of the eternal Wait() in CrashIfHangingRunnable::DispatchAndWait
- Augment the runnable to use an boolean to track whether or not it has effectively "resolved" with an answer so that we only write to mMsg exactly once. While the call to Wait(timeout) indicates what happened with its CVStatus return, it's necessary to make sure that WorkerRun/Cancel check this value before potentially mutating mMsg in the event they actually do run after the timed wait has given up.
- Add crash information, if the worker is a Chrome worker and in case add the executed script URL
Differential Revision: https://phabricator.services.mozilla.com/D92204
This commit adds the boilerplate machinery for the function-references proposal. The
interesting piece is that the GC proposal is moved to require the function-references
proposal to be enabled.
The configuration machinery for features is refactored in this commit to avoid passing
6 different booleans around as parameters to functions.
* A FeatureArgs struct is added with values for all 'feature' configuration options
- A feature is defined as an option that affects validation or semantics
- Essentially everything besides 'debug', 'mode', 'tier'
* All feature configuration responsibility is removed from CompilerEnvironment
* ModuleEnvironment is modified to accept a FeatureArgs in addition to a
CompilerEnvironment
- The CompilerEnvironment field may eventually be removed, as it's not needed
within function validation, and is only used by the compilers later
Differential Revision: https://phabricator.services.mozilla.com/D89857
This patch was generated by running:
```
perl -p -i \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF8toUTF16\((.*)\);/\1CopyUTF8toUTF16(\3, \2);/;' \
-e 's/^(\s+)([a-zA-Z0-9.]+) = NS_ConvertUTF16toUTF8\((.*)\);/\1CopyUTF16toUTF8(\3, \2);/;' \
$FILE
```
against every .cpp and .h in mozilla-central, and then fixing up the
inevitable errors that happen as a result of matching C++ expressions with
regexes. The errors fell into three categories:
1. Calling the convert functions with `std::string::c_str()`; these were
changed to simply pass the string instead, relying on implicit conversion
to `mozilla::Span`.
2. Calling the convert functions with raw pointers, which is not permitted
with the copy functions; these were changed to invoke `MakeStringSpan` first.
3. Other miscellaneous errors resulting from over-eager regexes and/or the
replacement not being type-aware. These changes were reverted.
Differential Revision: https://phabricator.services.mozilla.com/D88903
This adds the preference, JS shell option, and {ContextOptions,CompileOptions} fields,
but the value isn't read and the code always acts as it's set to true.
Differential Revision: https://phabricator.services.mozilla.com/D88922
This runs an extra GC cycle when a worker goes idle if the cycle collector collected anything. This fixes the test case given (but not the case in the original bug).
Differential Revision: https://phabricator.services.mozilla.com/D82869
