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
- Fixes a data race where the member variable is being written to by
EnsurePerformanceCounter on the worker thread while being read on a separate
thread (via Worker.postMessage).
- Apply some pointer guildelines to the member variable getters.
- Constify some things that should be const.
Differential Revision: https://phabricator.services.mozilla.com/D82475
Replace BROADCAST_ALL_WORKERS macro by a BroadcastAllWorkers member function.
Use RemoveIf instead of custom for loop.
Use range-based for where possible.
Use std::transform to transform an array into another instead of custom for loop.
Use std::copy_if for conditional copy of an array into another instead of custom for loop.
Differential Revision: https://phabricator.services.mozilla.com/D81056
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One affect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
WeakRef targets that are wrappers to DOM objects are preserved when the WeakRef is created. This checks whether the wrapper is still preserved in deref() and if it is found to have been released, the target is cleared.
The patch adds a new DOMJSClass hook to deal with getting the wrapper cache for non-nsISupports objects.
Differential Revision: https://phabricator.services.mozilla.com/D78061
This patch removes the dispatch of ReportGenericErrorRunnables when
a worker fails to start, since they were causing crashes and
weren't getting run anyway. It also adds an assertion that prevents
the creation of strong references to workers before they begin
their main loop.
Differential Revision: https://phabricator.services.mozilla.com/D76693
Bug 1594572 attempted to fix a shutdown edge-case where a worker that was
started late enough would fail to create a PBackground connection and
early return. This early return, however, left the worker never scheduled
for deletion, resulting in a shutdown hang. See my restating block at
https://phabricator.services.mozilla.com/D73134#2224963 for more context.
The problem with this was that the attempt to clear the main event queue
ran afoul of pre/post event-processing hooks intended to ensure that control
runnables are processed if some non-worker code goes and spins a nested
event loop on the worker thread. But because we never got around to
creating a cycle collected JS runtime on the thread, the call to get it
would return null and when we tried to get the recursion depth of a null
pointer, we would crash a little.
This patch addresses the immediate regression by adding a helper that returns
a depth of 1 in this edge-case. It also fixes another problem with the fix
that is now more obvious having reviewed bug 1636147... we were failing to
mark the status of the worker as dead and drain any control runnables, which
could have resulted in the CrashIfHangingRunnable usage not working out right.
(Note that CrashIfHangingRunnable does handle Cancel() correctly, so the
fact that we end up canceling the runnable shouldn't break things.)
Differential Revision: https://phabricator.services.mozilla.com/D75185
`RuntimeService::CrashIfHanging` uses `RuntimeService`'s registry
to determine which workers are still active. This approach is
flawed because the registry is updated on the main thread, so if
the main thread is stuck somewhere, dead workers could be reported
as active.
This commit adds an additional check: if dispatching a `Runnable`
to a worker fails, it assumes that the worker is dead. This way
main thread hangs would not be reported as worker hangs.
Differential Revision: https://phabricator.services.mozilla.com/D74256
