Changes:
- change how the modules are imported with the `absolute_import` changes
- satisfy python2 linter
Differential Revision: https://phabricator.services.mozilla.com/D37525
--HG--
extra : moz-landing-system : lando
This was kept to support old xul addons. All mozilla-central usages
have been removed and now uses Loader.jsm to get access to this module.
Differential Revision: https://phabricator.services.mozilla.com/D38321
--HG--
extra : moz-landing-system : lando
The rest was legacy code to support old xul add-ons.
All mozilla-central code used to be refactored, but a few places
were still using the old codepaths.
Differential Revision: https://phabricator.services.mozilla.com/D38283
--HG--
extra : moz-landing-system : lando
Update the browsertime snapshot to 4989d0c22bba3a165078b8d784e8d303a727a119 which uses lodash 4.7.14 and lodash.merge 4.6.2.
Differential Revision: https://phabricator.services.mozilla.com/D37806
--HG--
extra : moz-landing-system : lando
Rather than relying on the mar-channel-id set in the `mar` binary, set the channel
explicitly from taskcluster. This allows us to re-use the `mar` binary between
builds/channels.
Differential Revision: https://phabricator.services.mozilla.com/D37481
--HG--
extra : moz-landing-system : lando
This case is expected in the mozlint world (e.g, when running all linters).
This will still print a warning, just a far less scary one and will still
return 0. There is a case to be made that we should silently ignore this as no
other linters print this warning, but it's useful enough to warrant keeping.
Differential Revision: https://phabricator.services.mozilla.com/D37414
--HG--
extra : moz-landing-system : lando
The goal is to have something simple and not relying on other tools.
I tried with licensecheck and licensee but, with if we use a different
wording to declare "public domain" (as example), they might not
catch it. Requiring to contribute upstream, etc
Instead, I just create a list of line of license to catch it.
From my trials, it works well enough and it is trivial python.
Differential Revision: https://phabricator.services.mozilla.com/D37082
--HG--
extra : moz-landing-system : lando
Also change ANGLE's checkout to 'gfx/angle/checkout' instead of
'gfx/angle'.
Differential Revision: https://phabricator.services.mozilla.com/D37340
--HG--
extra : moz-landing-system : lando
Changes:
- change syntax of all python files under `dom/canvas/test` to python3 syntax
- remove semicolon line terminators from `dom/canvas/test/webgl-conf/checkout/deqp/genHTMLfromTest.py`
Differential Revision: https://phabricator.services.mozilla.com/D36388
--HG--
extra : moz-landing-system : lando
Changes:
- nothing changed except removing `modules/freetype2` from the blacklist
Differential Revision: https://phabricator.services.mozilla.com/D35701
--HG--
extra : moz-landing-system : lando
Often times, PGO builds aren't required for testing things (in particular,
testing release automation). However, at least when testing release automation,
we do need to use the shippable build type.
Add an option to mach try that will disable using the 3-tier PGO jobs.
Differential Revision: https://phabricator.services.mozilla.com/D36365
--HG--
extra : moz-landing-system : lando
Templates invoke the `morph` logic, which is somewhat confusing and inflexible.
Update the machinery to support setting other `try_task_config` values.
Differential Revision: https://phabricator.services.mozilla.com/D36364
--HG--
extra : moz-landing-system : lando
Factor out the logic for calculating `try_task_config` from `push_to_try`,
so it can be called only for those selectors that need it.
Differential Revision: https://phabricator.services.mozilla.com/D36363
--HG--
extra : moz-landing-system : lando
Instead of setting entry&exit function when Gecko Profiler is initialized, we
now set them when profiling actually starts, and reset them when profiling
stops. There may be edge cases (missing or unneeded labels at the very start or
end of a session) are not an issue.
Differential Revision: https://phabricator.services.mozilla.com/D34808
--HG--
extra : moz-landing-system : lando
`ProfilingStack*` happens to be the information that the current Gecko Profiler
entry function wants to forward to the exit function, but AutoProfilerLabel does
not really need to know about that.
Changing it to `void*`, so that we can later use different entry/exit functions
that use different context types.
Differential Revision: https://phabricator.services.mozilla.com/D34806
--HG--
extra : moz-landing-system : lando
If `./mach browsertime` runs browsertime with a globally-installed node, due to
an existing bug in [execa][1], the wrong Python will be executed. We now
specify the full path of the Python binary we wish to use (via the `PYTHON`
environment variable that our fork of browsertime supports) and avoid this
issue altogether.
[1]: https://github.com/sindresorhus/execa/issues/153
Differential Revision: https://phabricator.services.mozilla.com/D35374
--HG--
extra : moz-landing-system : lando
PowerOfTwo makes for a cleaner and more expressive interface, showing that the
profiler will use a power-of-2 storage size.
Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want
cheap modulo operations.
And we don't need to keep the original capacity, as it's only used once and can
easily be recomputed from the mask.
Differential Revision: https://phabricator.services.mozilla.com/D36027
--HG--
extra : moz-landing-system : lando
PowerOfTwo makes for a cleaner and more expressive interface, showing that the
profiler will use a power-of-2 storage size.
Using PowerOfTwoMask in ProfilerBuffer also makes it more obvious that we want
cheap modulo operations.
And we don't need to keep the original capacity, as it's only used once and can
easily be recomputed from the mask.
Differential Revision: https://phabricator.services.mozilla.com/D36027
--HG--
extra : moz-landing-system : lando
This moves the html plugin enabling from the ./mach command line to the configuration, which means editors can pick this up automatically.
Differential Revision: https://phabricator.services.mozilla.com/D35414
--HG--
extra : moz-landing-system : lando
Because the return address cannot be used to uniquely identify script/pc, this
is unfortunately quite different from what we do for Baseline/Ion code.
The strategy is as follows:
* When the profiler is enabled, ensure each JitScript has a pointer to the
profile string (released when the script is finalized).
* The BaselineInterpreter code is registered with the JitcodeMap.
* The profiler code treats interpreter frames like C++ Interpreter frames,
instead of doing the return address based mapping.
Differential Revision: https://phabricator.services.mozilla.com/D31052
--HG--
extra : moz-landing-system : lando
BIONIC is only platform that actually supports gettid. Easiest
solution is to check for linux and disable for BIONIC platform. This
includes the change requested by Gerald to keep the two profilers sync'd.
Differential Revision: https://phabricator.services.mozilla.com/D34919
--HG--
extra : moz-landing-system : lando
`jemalloc_replace_dynamic()` is badly broken. If you install a malloc table
other than the default at startup (e.g. DMD's or PHC's), when you call
`jemalloc_replace_dynamic()` it installs a new allocator that wraps the
*default* allocator, and then when you call `jemalloc_replace_dynamic(nullptr)`
it switches back to the *default* allocator.
This commits makes numerous improvements.
- It removes the "flip-flopping" between malloc tables, which didn't really
work and isn't necessary.
- `jemalloc_replace_dynamic()` now switches between the *original* malloc table
and the new one, rather than the *default* malloc table and the new one.
- It renames various things, to make the names shorter and clearer.
- It clearly documents the dangers and limitations of
`jemalloc_replace_dynamic()`.
- It removes and inlines `profiler::Init()`, because there was only one call
site.
- It rearranges `install_memory_counter()` so the control flow is simpler.
Differential Revision: https://phabricator.services.mozilla.com/D34266
--HG--
extra : moz-landing-system : lando
Changes include a fix for visual metrics calculations on desktop, and appending visual metrics information to gecko profiles.
Additionally, add the browsertime-results directory to gitignore.
Differential Revision: https://phabricator.services.mozilla.com/D34412
--HG--
extra : moz-landing-system : lando
Flip set_log_level to false by default so we don't clutter stdout. Flip on with --verbose.
Differential Revision: https://phabricator.services.mozilla.com/D34391
--HG--
extra : moz-landing-system : lando
The profiler will require non-fuzzed timers for accuracy. Making the switch early will avoid surprises when FuzzyFox is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D31010
--HG--
extra : moz-landing-system : lando
The vast majority of the virtual methods which were used on ProtocolState were
actually methods which only had meaningful implementations on the toplevel
protocol. This patch adds a new field to IProtocol holding a direct pointer to
the protocol's `IToplevelProtocol`, and the methods formerly implemented with
ProtocolState now directly call the corresponding method on IToplevelProtocol.
IToplevelProtocol then shadows these methods with the toplevel protocol
implementation, meaning that the right code is run in the right places.
In addition, some state was maintained for protocols inside of the separate
ProtocolState allocation, and this patch moves that state back into the actor
itself.
Differential Revision: https://phabricator.services.mozilla.com/D32044
--HG--
extra : moz-landing-system : lando
Using compatible release means that we will pick up minor updates to these
packages. Dependencies (i.e things not explicitly listed in the Pipfile), may
have their major versions updated as long as the package that uses them lists
it as compatible.
This will also allow us to update our dependencies' major/minor versions one at
a time. Using '*', Pipenv does not have any way of updating only a single
package at a time (that I could find).
Differential Revision: https://phabricator.services.mozilla.com/D33555
--HG--
extra : moz-landing-system : lando
Bug 1303806 moved `GeckoJavaSampler` to be Fennec-only as part of a general push
to slim GeckoView down. But there is no reason to restrict to Fennec and it is useful
for other non-Fennec GeckoView vehicles.
This patch moves the `GeckoJavaSampler` inside `geckoview` and changes profiler
code to make Java sampling work in both GeckoView and Fennec.
Depends on D33522
Differential Revision: https://phabricator.services.mozilla.com/D33502
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoJavaSampler.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoJavaSampler.java
extra : moz-landing-system : lando
If MOZ_BASE_PROFILER_STARTUP and MOZ_PROFILER_STARTUP are set, this will integrate
a pre-XPCOM startup profile into the main profile.
It is stored as separate threads (in a single JSON string that is moved around),
which will appear as a new track under the main process.
Only adding threads from BaseProfiler means a better integration with Gecko
Profiler profiles, and is more efficient: Less code, and a smaller memory
footprint.
Differential Revision: https://phabricator.services.mozilla.com/D31932
--HG--
extra : moz-landing-system : lando
Running identical (but separate) InitializeWin64ProfilerHooks in both profilers
confuses the DLL interceptor and the 2nd one crashes because of unexpected
opcodes introduced by the 1st one.
If MOZ_BASE_PROFILER is defined, Gecko Profiler will use that implementation of
InitializeWin64ProfilerHooks instead of its own; and that code also has a guard
so that it effectively only run once even if called from both profilers.
Differential Revision: https://phabricator.services.mozilla.com/D31931
--HG--
extra : moz-landing-system : lando
Notice the extra 'BASE' in the env-var names.
This is to control BaseProfiler separately from the Gecko Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D31928
--HG--
extra : moz-landing-system : lando
If MOZ_BASE_PROFILER_STARTUP and MOZ_PROFILER_STARTUP are set, this will integrate
a pre-XPCOM startup profile into the main profile.
It is stored as separate threads (in a single JSON string that is moved around),
which will appear as a new track under the main process.
Only adding threads from BaseProfiler means a better integration with Gecko
Profiler profiles, and is more efficient: Less code, and a smaller memory
footprint.
Differential Revision: https://phabricator.services.mozilla.com/D31932
--HG--
extra : moz-landing-system : lando
Running identical (but separate) InitializeWin64ProfilerHooks in both profilers
confuses the DLL interceptor and the 2nd one crashes because of unexpected
opcodes introduced by the 1st one.
If MOZ_BASE_PROFILER is defined, Gecko Profiler will use that implementation of
InitializeWin64ProfilerHooks instead of its own; and that code also has a guard
so that it effectively only run once even if called from both profilers.
Differential Revision: https://phabricator.services.mozilla.com/D31931
--HG--
extra : moz-landing-system : lando
Notice the extra 'BASE' in the env-var names.
This is to control BaseProfiler separately from the Gecko Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D31928
--HG--
extra : moz-landing-system : lando
Changes:
- require `--full` keyword for `./mach try fuzzy` in order to schedule android-hw jobs to hopefully reduce the backlog
Differential Revision: https://phabricator.services.mozilla.com/D33834
--HG--
extra : moz-landing-system : lando