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
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
Key features in this commit:
- support for `contentfulSpeedIndex` visual metric
- support for the Gecko Window Recorder (Desktop only)
- support for the Gecko Profiler (Desktop only)
- partial support for GeckoView on Android
Differential Revision: https://phabricator.services.mozilla.com/D32907
--HG--
extra : moz-landing-system : lando
Since it's not a xul document anymore we can't rely on the xul.js lint preprocessor.
This means we need to remove preprocessor attributes from inline scripts, and tell
lint about the browser window environment.
Differential Revision: https://phabricator.services.mozilla.com/D33207
when update-verify migrated from using build-tools to in-tree, the path
to `diff-summary.log` was not updated.
Differential Revision: https://phabricator.services.mozilla.com/D32403
--HG--
extra : moz-landing-system : lando
Two use cases:
1) Show the errors
$ ./mach lint -l rustfmt js/rust/src/rust.rs
Also works on a directory:
$ ./mach lint -l rustfmt js/rust/src/
2) Update the code
$ ./mach lint -l rustfmt js/rust/src/rust.rs --fix
To install it:
$ rustup component add rustfmt
$ export PATH=$PATH:~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/
Differential Revision: https://phabricator.services.mozilla.com/D30813
--HG--
extra : moz-landing-system : lando
Add Jitspewing control for tracelogger data. This can be enabled from the profiler or from the JS shell. Usage is as follows:
From browser (ION_SPEW_FILENAME is recommended here so stdout doesn't get clobbered by each process):
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger ION_SPEW_FILENAME=tracelogger ./mach run
2. Enable JSTracer feature in profiler addon
3. Start profiling and ctrl+shift+2 to view profile, and the data will be automatically spewed during profile collection.
From shell:
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger dist/bin/js test.js
2. Data is automatically spewed to stdout when the shell exits, or use ION_SPEW_FILENAME.
There is an optional environment variable JS_TRACELOGGER_SPEW that can be used to emit specific events, for example JS_TRACELOGGER_SPEW="Interpreter,Baseline,GC" will emit only those specific events along with the script and self time of each script.
The structured spewer is also supported with SPEW=tracelogger, and this will emit the tracelogger data for every recorded event.
Differential Revision: https://phabricator.services.mozilla.com/D30033
--HG--
extra : moz-landing-system : lando
Victor Porof
Nika Layzell
Zibi Braniecki
Ola Gasidlo
Andrew Halberstadt
Andrei Oprea
Nazım Can Altınova
Gerald Squelart
Noemi Erli
Edwin Gao
Bogdan Tara
Gijs Kruitbosch
Daniel Varga
Nick Alexander
arthur.iakab
Brian Grinstead
Mike Hommey
Ehsan Akhgari
Mihai Alexandru Michis
Sylvestre Ledru
Tom Prince
Andi-Bogdan Postelnicu
Denis Palmeiro
Boris Zbarsky