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
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
browser_Addons_sample is used by the browser_AddonWatcher.js test to make sure
we can properly detect when an add-on consumes a bunch of CPU or does a lot of
CPOW traffic.
There's a race condition in the add-on where what is supposed to be a CPOW
might not always be a CPOW, so when we try to cause a bunch of CPOW
traffic, we don't get the expected performance warnings.
This makes sure that when we try to simulate CPOW usage, we do it
with an actual CPOW.
Additionally, this commit also includes the unpacked source of the
add-on, which before wasn't in the tree. I've also taken the liberty
of bumping the add-on version and signing it.
MozReview-Commit-ID: GICLYpi8Kon
Although I haven't been able to pinpoint why, it looks like
nsPerformanceStatsService::Dispose() may be called twice, which in
turn causes crashes. This patch makes sure that calling the method
twice is idempotent.
Also, just in case this was due to a typo in
AddObserver/RemoveObserver, this patch replaces the literal strings
used in both with constants.
MozReview-Commit-ID: 8fXO20r5xvO
