This is to avoid situations where a developer may call this from another thread, and get a confusingly incomplete profile.
Differential Revision: https://phabricator.services.mozilla.com/D133478
None of this is used now that `funsize` generates update MARs. It
might have even been possible to remove this in Bug 1173459, years
ago.
Differential Revision: https://phabricator.services.mozilla.com/D132836
First, add the "Busy test" thread to the filters, so it actually gets sampled!
Also check that each expected thread is present (this is how the above error was found).
And instead of expecting some zeroes/non-zeroes in idle/busy threads, which unfortunately can intermittently fail, just add up the CPU values for each thread, and we should at least expect that the busy thread will have done more work than the idle thread.
Differential Revision: https://phabricator.services.mozilla.com/D133170
This patch fixes the issue that was preventing the perfdocs hierarchy from being shown. It adds the toctree to the index.rst template and also modifies the generator to insert the required frameworks into the toctree.
Differential Revision: https://phabricator.services.mozilla.com/D133109
Future commits will tease this apart a bit more, but for now this helps
crystallize the order in which transforms are applied. The flow of the overall
test transforms goes something like this:
1. Enter 'transforms/test/__init__.py'
2. Validate all tasks against the test_description_schema
3. Run sibling transforms (starting with 'variant.py' and ending with 'other.py' for now)
4. Make the job description
As we pull more transforms out of 'other.py' and into their own smaller
transform files, it will be clear that the order in which these smaller files
run is important. Adding new transforms will no longer involve picking some
random spot to insert it.
Differential Revision: https://phabricator.services.mozilla.com/D132409
The profiler uses GetProcInfoSync to discover unregistered threads, and record their CPU utilization. This data is captured in markers on the main thread track.
On Windows, because this work takes much longer than the usual sampling interval, it is done on its own thread.
Differential Revision: https://phabricator.services.mozilla.com/D132213
When constructing the SamplerThread object, individual features were extracted from the feature set (a uint32_t), and passed as bools. This could be error-prone, wasteful, and a maintenance burden when more features are needed in some/all platform implementations (like the next patch adding a new feature with a Windows-specific impact).
So now the full feature set is given to the SamplerThread, which can then extract the features it requires on each platform.
Differential Revision: https://phabricator.services.mozilla.com/D132523
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
Build and run the Mach virtualenv from a `state_dir` that is
"specific-to-topsrcdir".
As part of this, move `get_state_dir()` to `mach` so that it's usable
before `sys.path` entries are fully set up.
Differential Revision: https://phabricator.services.mozilla.com/D130383
This includes:
transforms/tests.py -> transforms/test/__init__.py
transforms/raptor.py -> transforms/test/raptor.py
This is a pre-cursor to splitting the file up into multiple smaller files under
the new 'test' transform directory.
Differential Revision: https://phabricator.services.mozilla.com/D132068
Consolidate Mach virtualenv management to the front of the
Mach process. This obsoletes `./mach create-mach-environment`
and simplifies the `sh` portion of the top-level `./mach` script.
This helps ensure that the Mach virtualenv doesn't become
out-of-sync and simplifies the mental model of the Mach
virtualenv situation.
Differential Revision: https://phabricator.services.mozilla.com/D120401
It was in `nativecmds` to make finding `pip3` easier.
However, since we're removing the distinction between "regular" and
"native" cmds (Mach will create and activate its venv naturally during
initialization), we need to start pruning the `nativecmds` list.
Fortunately, we can use the stored "external_python" value to decide
where to install "moz-phab" to.
The new behaviour continues to support the following use cases:
* Using Mach with system Python in the `$PATH`.
* Using Mach from within a human-managed virtualenv.
* Either of the above^ in combination with `MACH_USE_SYSTEM_PYTHON`.
Differential Revision: https://phabricator.services.mozilla.com/D120397
This version of minidump-stackwalk is now replaced with rust-minidump's
minidump-stackwalk, which we build from a FETCH. Not touching the other
stuff in this directory because I have no idea what it is.
Differential Revision: https://phabricator.services.mozilla.com/D131316
This patch adds 4 new interactive tests for facebook and reddit. The patch updates the recordings as well as needed. Furthermore, an update to the visualmetrics.py script is needed to handle a permafailure in the reddit-post tests. Note that the reddit-post test was split in 2 since they are quite large.
Differential Revision: https://phabricator.services.mozilla.com/D130665
On some platforms (e.g., Mac beta or release), native stack-walking is currently unavailable. In this case, simple tests with with no labels (or other non-native frames) would be totally empty, and would fail when expecting any data in the "samples" sections of profiles.
This is fixed by adding one label, which guarantees that stacks won't be empty.
Differential Revision: https://phabricator.services.mozilla.com/D131100
As `_run_pip()` is being removed from `VirtualenvManager` in an upcoming
patch, its usages need to be removed. Besides, they're using an
"internal" function, which is a bit of a smell.
Note that this _could_ have been solved by exposing a public `run_pip()`
function. However, I felt like that was worse because:
* Friction here is good as we try to migrate the codebase to embrace the
"requirements definition file" technique to install dependencies.
* There could be confusion about the relationship between
`install_pip_package()` (only works if venv already activated)
and `_run_pip()`, which works "in general".
Differential Revision: https://phabricator.services.mozilla.com/D130120
Gerald Squelart
Nick Alexander
Kimberly Sereduck
Noemi Erli
Mark Banner
Agi Sferro
Steve Fink
Gregory Mierzwinski
Myeongjun Go
Dan Minor
Butkovits Atila
Andrew Halberstadt
Julian Descottes
Sylvestre Ledru
Chris Peterson
Mitchell Hentges
Emilio Cobos Álvarez
Renovate Bot
Christian Holler
Nika Layzell
afinder
Alexis Beingessner
Miko Mynttinen
Will Kahn-Greene