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
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
Now starting with a maximum of `1u << 22`, i.e. 4,194,304 entries, or 36MB per
process. (Using powers of two, because that's what we round up to anyway.)
Also giving more information in MOZ_PROFILER_HELP:
- Reminding this is a number of entries *per process*.
- Bytes per entry, and resulting total buffer sizes per process.
Differential Revision: https://phabricator.services.mozilla.com/D31389
--HG--
extra : moz-landing-system : lando
There were many inconsistent ways to retrieve process/thread ids in the
profiler. Now we have only one platform-dependent implementation each:
profiler_current_process_id() and profiler_current_thread_id().
Note that this removes the need for the small `class Thread` in platform.h.
However memory_hooks.cpp still needs to be built non-unified, because of the
required order of #includes (replace_malloc.h before replace_malloc_bridge.h),
which could be disturbed by other cpp's.
Differential Revision: https://phabricator.services.mozilla.com/D29977
--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
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
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
This is similar to AUTO_PROFILER_LABEL, but with only one argument: a category pair.
This reduces duplication for label frames that want just the subcategory name as
their label: Instead of AUTO_PROFILER_LABEL("Layer building", GRAPHICS_LayerBuilding),
you can now just write AUTO_PROFILER_LABEL_CATEGORY_PAIR(GRAPHICS_LayerBuilding) and
the string will automatically be taken from the subcategory.
Differential Revision: https://phabricator.services.mozilla.com/D11339
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
Profiler was previously fetching process name at the time of shutdown
serialization, at which point that name could have already been destroyed.
Now the child process just forwards the name as soon as it is given, so
the profiler can store it for later.
Differential Revision: https://phabricator.services.mozilla.com/D19732
--HG--
extra : moz-landing-system : lando
Bug 1526508 - add profiler markers for importing a JS module, loading a JS XPCOM component or a subscript
Differential Revision: https://phabricator.services.mozilla.com/D19228
--HG--
extra : moz-landing-system : lando
Found issues by forcing a local non-unified build.
Also sorted #includes by logical groups (from most local to most global), and
alphabetically within groups.
Depends on D18621
Differential Revision: https://phabricator.services.mozilla.com/D18622
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
We can directly set environment variables for the child process on
all platforms now, instead of changing the parent's environment and
inheriting the changes. This simplifies memory management, but more
importantly it's necessary for thread safety to allow launching
processes from a thread pool.
Depends on D8944
Differential Revision: https://phabricator.services.mozilla.com/D8945
--HG--
extra : moz-landing-system : lando
Add a new class to extract tracelogger data using chunked buffers and use this to write the data out to the profiler JSON output. Copying the data in chunks lets us minimize our memory overhead when writing out to the profiler so a large array of millions of elements does not need to be allocated ahead of time.
Differential Revision: https://phabricator.services.mozilla.com/D11791
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
We can directly set environment variables for the child process on
all platforms now, instead of changing the parent's environment and
inheriting the changes. This simplifies memory management, but more
importantly it's necessary for thread safety to allow launching
processes from a thread pool.
Depends on D8944
Differential Revision: https://phabricator.services.mozilla.com/D8945
--HG--
extra : moz-landing-system : lando
profiler_thread_is_being_profiled() checks if the profiler is active (quick
inline atomic check) and if the current thread is being profiled (function call
doing a TLS-atomic check).
This may be used instead of profiler_is_active() for thread-specific recordings
(e.g.: markers).
Differential Revision: https://phabricator.services.mozilla.com/D11307
--HG--
extra : moz-landing-system : lando
Added a mechanism to register and unregister the DocShells from the CorePS depending
on the state of the profiler. Registering mechanism is straightforward. During
unregistration, if profiler is not active, we remove the DocShell information
immediately. If profiler is active, we don't remove and we keep the profiler buffer
position at that moment. During another DocShell registration we Discard the
unregistered DocShells. If the profiler buffer position is greater than the position
when we captured during unregistration, we delete the DocShell since that means there
can't be any markers associated to this DocShell anymore.
MozReview-Commit-ID: IVuKQ6drvkR
Differential Revision: https://phabricator.services.mozilla.com/D4914
--HG--
extra : moz-landing-system : lando