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
These pragmas can be used to influence stack trace filenames, and to affect
how and where files show up in developer tools. In some circumstances, it can
be nice to disable allof that functionality in order to ensure that you get
the stack trace and debug information as SpiderMonkey sees it.
Differential Revision: https://phabricator.services.mozilla.com/D72103
We add a configuration option for SIMD and apply ENABLE_WASM_SIMD
throughout the engine as appropriate, mostly to insert #error or
MOZ_CRASH where things need to be done in later patches or for
architectures that we won't currently consider.
We add a command line switch for the shell and an option for
about:config and plumb the value of this through the engine.
Differential Revision: https://phabricator.services.mozilla.com/D57940
This requires adding a new JSOptions field (for internal use within the shell),
as well as a new browser pref (to support possible Cranelift benchmarking on
aarch64).
Differential Revision: https://phabricator.services.mozilla.com/D72907
If we try to start a worker too close to shutdown, the main runnable for its
thread runs after shutdown has begun, bails out early trying to create a
BackgroundChild for its thread. Unlike bail-outs in WorkerPrivate::DoRunLoop,
though, nothing winds up scheduling the deletion of the worker after it
returns, and afterwards the worker is stuck forever in a pending state.
Attempts to shut it down from the main thread just dispatch an impotent
notification to be processed by the workers main event loop (which, of course,
will not ever happen).
This patch fixes the behavior of WorkerThreadPrimaryRunnable to always call
ScheduleDeletion when it exits, rather than only doing so when it succeeds
in entering the worker's main loop.
Differential Revision: https://phabricator.services.mozilla.com/D73134
WorkerThreadPrimaryRunnable possibly indirectly creates a
SendInitBackgroundRunnable (runs on the main thread), which causes a data race
with CompileScriptRunnable (runs on the worker thread) by having an
unsynchronized read/write of WorkerPrivate::mPerformanceCounter.
Differential Revision: https://phabricator.services.mozilla.com/D67434
--HG--
extra : moz-landing-system : lando
To correctly implement this, it must be known on instantiation whether E is
copy-constructible, which is not the case if only a forward declaration is
available. This can be resolved either by making sure a full definition of E is
available, which is preferable. But in cases where this is not (easily) possible,
the information can be explicitly provided by the MOZ_DECLARE_COPY_CONSTRUCTIBLE
and MOZ_DECLARE_NON_COPY_CONSTRUCTIBLE macros. In particular, declarations for
IPDL-declared types are added to nsTArray.h itself, like it was already done
for MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR.
Differential Revision: https://phabricator.services.mozilla.com/D66244
--HG--
extra : moz-landing-system : lando
