cppunittest TestBaseProfiler and gtest GeckoProfiler.Markers now show overhead
stats.
(Separate patch, because we may want to remove them after a while.)
Differential Revision: https://phabricator.services.mozilla.com/D39642
--HG--
extra : moz-landing-system : lando
`ProfileBuffer` is now responsible for collecting overhead stats, and adding
them to the struct returned by `profiler_get_buffer_info()`.
Differential Revision: https://phabricator.services.mozilla.com/D39641
--HG--
extra : moz-landing-system : lando
`SamplerThread` inheriting from `Sampler` was a bit confusing, and scary with no
virtual destructor&functions.
`SamplerThread` only uses `Sampler`'s `Disable()` and
`SuspendAndSampleAndResumeThread()` functions, and `SamplerThread` is never
accessed through a `Sampler` reference/pointer.
So `SamplerThread` can just own a `Sampler` to make that relationship clearer.
Differential Revision: https://phabricator.services.mozilla.com/D39640
--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
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
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
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
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
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
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
