Memory tracks are fed from a memory counter, which is unconditionally installed
from profiler_start(). This means:
- It is installed even if memory measurements are not requested.
- Startup profiling doesn't use profiler_start() and therefore never starts
recording memory.
Because installing the memory counter may need to take the (non-recursive)
profiler lock, it cannot simply be installed from the common
`locked_profiler_start()` function.
Instead, it will have to be installed after each `locked_profiler_start()` call.
Also, it should only be installed if the "memory" feature is requested.
That "memory" feature is now considered available only if Firefox was built with
MOZ_REPLACE_MALLOC and MOZ_PROFILER_MEMORY. (This may effectively prevent the
old RSS&USS memory reporting which doesn't depend on these #defines, but This Is
Fine as it is not used anymore and slated for removal in bug 1521929.)
Differential Revision: https://phabricator.services.mozilla.com/D25533
--HG--
extra : moz-landing-system : lando
Startup-profiling usually needs to capture more data, especially on slower
systems, so the default is changed to 10 million entries when
MOZ_PROFILER_STARTUP is set.
Also:
- Changed #define into `static constexpr` with the same type as expected by
`profiler_start()`.
- Better validity check of MOZ_PROFILER_STARTUP_ENTRIES.
- Defaults are shown in MOZ_PROFILER_HELP.
Differential Revision: https://phabricator.services.mozilla.com/D25689
--HG--
extra : moz-landing-system : lando
MOZ_PROFILER_FEATURES is mostly used to add features in addition to the
defaults. This will now be easier, e.g.:
`MOZ_PROFILER_STARTUP_FEATURES=default,screenshots`
Differential Revision: https://phabricator.services.mozilla.com/D25532
--HG--
extra : moz-landing-system : lando
It is too easy to mistype a feature name, and be confused or misled by the
results. This patch will catch such errors.
The previous code was going through each possible feature, seeing if it was in
MOZ_PROFILER_STARTUP_FEATURES -- Meaning unknown names would just be ignored.
The new code is doing the reverse: Going through all names in
MOZ_PROFILER_STARTUP_FEATURES, trying to match each one with possible features;
if not found, we indicate the first name that is unknown, show the help and
exit.
Differential Revision: https://phabricator.services.mozilla.com/D25531
--HG--
extra : moz-landing-system : lando
Show the list of MOZ_PROFILER_STARTUP_FEATURES with their value, name,
description, and whether they are default and/or available on this platform.
Feature descriptions are now provided in PROFILER_FOR_EACH_FEATURE.
Available features and defaults are now defined in one place, for easier
maintenance.
Differential Revision: https://phabricator.services.mozilla.com/D25530
--HG--
extra : moz-landing-system : lando
Moving to non-XPCOM data structures, to help with upcoming transfer to mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D24698
--HG--
extra : moz-landing-system : lando
Moving to non-XPCOM data structures, to help with upcoming transfer to mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D24697
--HG--
extra : moz-landing-system : lando
Some macros would not work if they were used in a context where `namespace
mozilla` is not directly accessible. Fixed by added appropriate `mozilla::`
specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D28028
--HG--
extra : moz-landing-system : lando
As the third-party node modules are throwing errors while running ./mach lint, the path was added to the ignore list for third party folders / files.
Differential Revision: https://phabricator.services.mozilla.com/D28620
--HG--
extra : moz-landing-system : lando
It turns out there are several places where the change to suite 'jittest-chunked'
causes problem. I am abandoning that approach.
Desktop uses this trick, and this returns android '-chunked' handling to a state
similar to what it was before I started messing around!
Differential Revision: https://phabricator.services.mozilla.com/D28897
--HG--
extra : moz-landing-system : lando
This skips a number of talos jobs that are unlikely to be affected
by due a browser-chrome specific change
Run with: `./mach try fuzzy --preset perf-chrome`
Differential Revision: https://phabricator.services.mozilla.com/D27911
--HG--
extra : moz-landing-system : lando
This officially makes 'moztest.resolve' the source of truth when it comes to
suite names. It aligns that file with the names used in both the
desktop_unittest and android_emulator_unittest scripts.
Differential Revision: https://phabricator.services.mozilla.com/D27555
--HG--
extra : moz-landing-system : lando
Currently we have the concept of a "suite" and a "flavour" in our task
configuration. Typically, the "suite" refers to the high-level test harness
like "mochitest" or "reftest", whereas the flavour is more specific, e.g
"browser-chrome-instrumentation" or "crashtest". However the line between suite
and flavour is not applied with any semblance of consistency which results in
inconsistent naming throughout the tree.
This patch gets rid of the concept of "flavours" entirely (at least when it
comes to task configuration). A suite is a type of test run, for example:
- mochitest-plain
- mochitest-devtools-chrome
- mochitest-browser-chrome-instrumentation
- jsreftest
- reftest
- firefox-ui-functional-remote
etc
There is no confusion here between suites and flavours because flavours don't
exist. However, there are a couple of places where we *do* need to know what
"test harness" is used to run a suite. These cases are:
1. For SCHEDULES moz.build rules
2. For the desktop_unittest.py mozharness script which takes arguments like
--mochitest-suite=browser (this is not a compelling use of this information
and should be refactored to work more like the android_emulator_unittest.py
script)
So to get this information, this patch introduces a new concept of a "category"
which is the overall "test harness" that runs the suite. For many suites, the
"category" is identical to the suite name. Unlike flavours, "categories" have
no bearing on how we call or refer to the suite.
Differential Revision: https://phabricator.services.mozilla.com/D27554
--HG--
extra : moz-landing-system : lando
This was regressed by bug 1544816 but the test never ran on the push that regressed.
This patch also updates the 'files-changed' for the tryselect task.
Differential Revision: https://phabricator.services.mozilla.com/D28386
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
Changes:
- added windows10-aarch64 to the filter for fuzzy, to require `--full` in order to trigger jobs
- return False for any test tasks that contain windows10-aarch64 to prevent users using old try syntax from overwhelming the limited number of hardware
Differential Revision: https://phabricator.services.mozilla.com/D27590
--HG--
extra : moz-landing-system : lando
Since e10s is the default configuration, we shouldn't explicitly mark things
with the "-e10s" suffix. Instead we should mark things that *don't* run with
'e10s. This patch removes '-e10s' from all treeherder group symbols and task
labels, adds the "-1proc" suffix to tasks that are non-e10s.
Differential Revision: https://phabricator.services.mozilla.com/D25958
--HG--
extra : moz-landing-system : lando
This helps run the tests locally if fzf is normally installed in
$HOME/.mozbuild. Since the tests set MOZBUILD_STATE_PATH to a temporary
directory, fzf_bootstrap() can't find fzf in the HOME location unless it
is added to PATH.
Differential Revision: https://phabricator.services.mozilla.com/D27194
--HG--
extra : moz-landing-system : lando
Add Android 7.0 gtests, opt and debug, running against the geckoview
TestRunnerActivity.
Differential Revision: https://phabricator.services.mozilla.com/D27016
--HG--
extra : moz-landing-system : lando
This patch enables compilation of the tracelogger by default on nightly builds
as well as providing an environment variable (JS_TRACE_LOGGING) to enable or
disable tracelogger instrumentation when compiling Javascript. This helps to
reduce the performance impact of the Tracelogger code when not in use. In the
future, this could be improved to recompile the JS with/without Tracelogger
instrumentation when toggling Tracelogger support.
Differential Revision: https://phabricator.services.mozilla.com/D26255
--HG--
extra : moz-landing-system : lando
Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
We always pass in the platform formated as an update platform. Since the only
variation in formats is between major platforms, be liberal in parsing
platforms, when selecting which unpack logic to use. This makes win64-aarch64
support fall out automatically.
Differential Revision: https://phabricator.services.mozilla.com/D26201
--HG--
extra : moz-landing-system : lando
We always pass in the platform formated as an update platform. Since the only
variation in formats is between major platforms, be liberal in parsing
platforms, when selecting which unpack logic to use. This makes win64-aarch64
support fall out automatically.
Differential Revision: https://phabricator.services.mozilla.com/D26201
--HG--
extra : moz-landing-system : lando
These modules are MIT licensed and they're to be used in xpcshell-tests for TRR.
They allow us to make moz-http2.js act like a true DoH server - more specifically to answer DNS queries that have actually been asked, not just a dumb character buffer.
Differential Revision: https://phabricator.services.mozilla.com/D25672
--HG--
extra : moz-landing-system : lando
These modules are MIT licensed and they're to be used in xpcshell-tests for TRR.
They allow us to make moz-http2.js act like a true DoH server - more specifically to answer DNS queries that have actually been asked, not just a dumb character buffer.
Differential Revision: https://phabricator.services.mozilla.com/D25672
--HG--
extra : moz-landing-system : lando
There are a few windows/mac-only suites that were missed since we were only
reading the linux variant.
Depends on D25401
Differential Revision: https://phabricator.services.mozilla.com/D25432
--HG--
extra : moz-landing-system : lando
While running presets + intersection queries works with 'mach try fuzzy
--preset <foo>', it is still broken with 'mach try --preset <foo>'.
Differential Revision: https://phabricator.services.mozilla.com/D25298
--HG--
extra : moz-landing-system : lando
Some of these were working with the '<flavor>-<subsuite>' mechanism that was
previously being used, but better to be explicit wherever possible.
Depends on D25077
Differential Revision: https://phabricator.services.mozilla.com/D25078
--HG--
extra : moz-landing-system : lando
Mozharness appends -chunked/-coverage to some suites, but the build system/test
resolver don't have any concept of these things. We need to normalize these out
for the purposes of MOZHARNESS_TEST_PATHS.
Differential Revision: https://phabricator.services.mozilla.com/D25015
--HG--
extra : moz-landing-system : lando
It turns out bug 1489100 regressed the ability to specify test paths for most
suites by naively assuming that mozharness uses suite names that look like:
<flavor>-<subsuite>
In reality, there is no consistency to how suite names are generated. This test
does a few things:
1) Patches the moztest.TestResolver to return a list of all possible
suites/subsuites (assuming the lists in moztest.resolve are up to date).
2) Finds all the suites defined in the mozharness configs (e.g
linux_unittest.py), and uses these are parametrized inputs.
3) Checks that for each test suite,
DesktopUnittest._get_mozharness_test_paths() returns something.
I've marked all of the test suites that currently fail as expected. This way I
have a good sense of what needs to be fixed, and can validate my changes as I
move through the list.
Differential Revision: https://phabricator.services.mozilla.com/D25014
--HG--
extra : moz-landing-system : lando
Disable the following tests for windows10-aarch64:
- test_enterjit_osr.js
- test_feature_mainthreadio.js
They were likely intermittents at first, but as of recent try push noted below these tests are failing consistently.
Differential Revision: https://phabricator.services.mozilla.com/D24413
--HG--
extra : moz-landing-system : lando
The graph contains some extra things like toolchains, fetches and packaging
tasks that people will almost never want to run on their own. This change gets
them out of the default fuzzy selection interface, and makes it so --full is
needed to schedule them.
Differential Revision: https://phabricator.services.mozilla.com/D24187
--HG--
extra : moz-landing-system : lando
This makes RAPL abort with more informative error messages if certain
kernel-provided files aren't present.
Differential Revision: https://phabricator.services.mozilla.com/D23974
--HG--
extra : moz-landing-system : lando
Not only is it best practice to pin dependencies and check hashes, but this
will allow tests to install these dependencies as well.
Depends on D22784
Differential Revision: https://phabricator.services.mozilla.com/D22785
--HG--
extra : moz-landing-system : lando
Flake8 ignores the 'exclude' section of the .flake8.yml if you pass in a direct
path to a file. To get around this we have some custom logic to handle these
exclusions for us, but this custom logic didn't account for globs.
Differential Revision: https://phabricator.services.mozilla.com/D23145
--HG--
extra : moz-landing-system : lando
New glibc versions provide a wrapper for gettid, which means that our stuff
fails to build with:
```
/home/emilio/src/moz/gecko/js/src/util/NativeStack.cpp:28:14: error: static declaration of 'gettid' follows non-static declaration
static pid_t gettid() { return syscall(__NR_gettid); }
^
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration is here
extern __pid_t gettid (void) __THROW;
```
Differential Revision: https://phabricator.services.mozilla.com/D22829
--HG--
extra : moz-landing-system : lando
I initially forgot that this test should only be run on nightly, as the
interposer is disabled on release and beta.
Differential Revision: https://phabricator.services.mozilla.com/D22982
--HG--
extra : moz-landing-system : lando
Some system libraries such as libart.so doesn't have CFI, so I want to add
stack walker that uses frame pointer when no rule set, like x86/x86-64.
Differential Revision: https://phabricator.services.mozilla.com/D18918
--HG--
extra : rebase_source : 4c8edef9a02d6fdb213e3a78731631ee0703650f
This forces us to be more strict with what gets passed into the try selector.
This change means test_preset.py will error if someone makes a typo in an
in-tree preset.
Differential Revision: https://phabricator.services.mozilla.com/D22024
--HG--
extra : moz-landing-system : lando
When we parse template arguments, we stuff them all in kwargs['templates'],
however we don't delete the old argument. This results in all kinds of unused
variables lying around in kwargs. E.g we would have both
kwargs['templates']['env'] and kwargs['env'] (the latter being unused). This is
the main reason why all the selector's run functions need to have a **kwargs at
the end of them.
Depends on D22022
Differential Revision: https://phabricator.services.mozilla.com/D22023
--HG--
extra : moz-landing-system : lando
This was previously only in the cli parser because that was the only shared
place that ran for all selectors. Now that we have the 'self.run' function in
mach_commands.py, we can move it there. This move is also needed to allow us to
remove 'templates' from kwargs (which happens in the next commit).
Depends on D22021
Differential Revision: https://phabricator.services.mozilla.com/D22022
--HG--
extra : moz-landing-system : lando
This allows us to refactor mach_commands.py so we can call self.handle_presets
implicitly. This in turn gives us a future place to add shared code and makes
adding new selectors easier.
Differential Revision: https://phabricator.services.mozilla.com/D22021
--HG--
extra : moz-landing-system : lando
This creates a global preset file at:
tools/tryselect/try_presets.yml
Any presets defined here will be available for everyone to use.
Differential Revision: https://phabricator.services.mozilla.com/D21435
--HG--
extra : moz-landing-system : lando
This will make it possible to have multiple instances of PresetHandler to
support multiple preset files.
Differential Revision: https://phabricator.services.mozilla.com/D21429
--HG--
extra : moz-landing-system : lando
