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
--HG--
extra : rebase_source : 92d4b775a7a7cbb5793e74eea471be81be974dda
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
--HG--
extra : rebase_source : bb205970b4186d9325dded7ddae066bcad18fb0e
- `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
--HG--
extra : rebase_source : 251455d8a3450795eb9dcb05c46f6c4d6e2c7810
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
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
--HG--
extra : rebase_source : 490f1a5186a426a41ab567e564cdbd46080262ec
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
--HG--
extra : rebase_source : 8b2eada3f9c80fe9feff880e985739a368e7b997
This patch (currently WIP) alters the way we determine whether jank is user-visible or not.
Instead of measuring the total time spent doing JS, we now use an
indicator provided by the vsync driver: how long it takes to deliver
the signal from the vsync timer to the main thread. This lets us find
out more accurately if there is user-visible jank. In the future, this
will also let us add an observer to find out whether the process
itself is janky, regardless of JS.
--HG--
extra : rebase_source : a538e3cc9d8904f52d4a0e7bad291189986e4e6d
To decrease the number of apparent false positives, we classify jank
alerts as visible or invisible. We use the following heuristic:
- if the process is currently animating something, any jank alert is visible;
- if the process has just handled a user input, any jank alert is visible;
- if some user input is handled during the current iteration, any jank alert is visible;
- otherwise, jank alerts are not visible.
--HG--
extra : rebase_source : 450661fb1106429a455b3e9f8f66fc477c22ccef
This patch introduces a new API to the nsPerformanceStatsService to register observers for slow performance. This API has several advantages:
- as it doesn't require polling, it also doesn't need to wake up the parent process every 15 seconds for the AddonWatcher;
- as it doesn't require polling, it doesn't need to wake up the child processes every time we wish to obtain data on slow performance;
- as it provides immediate data on performance alerts, it makes it possible to get rid of the complex and expensive post-processing performed by JS to merge data from all processes and attempt to extract performance alerts.
The old API is still available.
--HG--
extra : transplant_source : %84%B11%D3n%B4y%AAM%7C%B02%5E%3C%BA%B0%93%B6%FF%D5
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
