This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This new module simplifies how we interact with PerformanceInfo counters:
- CollectPerformanceInfo: returns all PerformanceInfo instances
- NotifyPerformanceInfo: converts PerformanceInfo in XPCOM and notify them
MozReview-Commit-ID: JedKEtsbQTF
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
This is a temporary workaround to avoid the intermittent orange. We still need to track down what the
underlying cause of the difference in timings between compartments and processes really is.
MozReview-Commit-ID: GmT67UDuTqN
This removes all the code for add-on performance watching from the
perfmonitoring component. This should mean that for add-on
compartments, we no longer trigger jank or CPOW monitoring in the JS
engine. This should result in minor performance improvements. As a
result, about:performance no longer reports on add-on performance
(but still reports on web page performance).
It also removes the AddonWatchers.jsm module and the related Nightly-
only UI (disabled in the parent commit) and strings. This UI wasn't
ready for release, there wasn't sufficient data it was creating
value for users, and there was some evidence that it didn't always
correctly identify the cause of performance issues, thus potentially
leading to user confusion or annoyance. Removing it therefore seemed
the right thing to do.
MozReview-Commit-ID: LsRwuaUtq6L
This patch fixes two related issues.
1. The AutoStopwatch uses a stack-allocated `mozilla::Vector` to
communicate with its callback during each compartment switch. This
vector was designed to allow its contents to be stack-allocated but
they turned out to be accidentally heap-allocated.
2. During each tick, the stopwatch fills a vector
`recentGroups_`. This vector always started with minimal capacity and
had to grow repeatedly as groups were added, causing repeated
reallocations. This patch preallocates `recentGroups_` to have the
same capacity as the previous tick. We expect that this should
eventually reach a stable size that closely matches the actual needs
of the process.
MozReview-Commit-ID: A7e3HNdSuML
Running eslint with --fix didn't fix many of the issues. The majority here had to be fixed by hand but a significant majority of the issues were related to a few files that I was able to use find-and-replace with. I regret not making this in to separate commits of the hand-fixes and the fixes from --fix but I don't recall --fix fixing any of the issues.
MozReview-Commit-ID: ANyg2qfo3Qx
- `totalCyclesDelta` is incremented whenever there is CPU usage in the topmost compartment *and* the execution of the topmost compartment stops on the same core as it started;
- each individual `cyclesDelta` is incremented whenever there is CPU usage in a compartment *and* the execution of the compartment stops on the same core as it started;
- however, with previous versions of Windows, the function to identify a core was not available, so the check was #ifdef-ed away.
It is therefore entirely possible that, at some point during the execution of a mochitest, the thread is rescheduled to another core in a way such that at least one compartment executes entirely on a core but the topmost compartment starts and stops on a different core.
Given that we're running on VMs that presumably run on timeshared servers, reschedulings are bound to be frequent, so it's hardly surprising that this always happens during the execution of mochitests.
The simplest would probably be to throw away results if `cyclesDelta > totalCyclesDelta` for any of `cyclesDelta`. We should check if this happens and, if so, reset stuff without actually committing data.
MozReview-Commit-ID: 3w2D1gtW4AQ