We use profiler categories to separate out the profiler markers for major
components, such as DOM or Layout, to quickly understand what is happening in
each of them: this will also be helpful for accessibility. One might be
concerned that we're adding too many categories but I think it's fine: the
accessibility category shouldn't appear if accessibility services aren't in use.
Furthermore, if accessibility code is running when it's unexpected, having the
accessibility category appear will only highlight that fact.
Differential Revision: https://phabricator.services.mozilla.com/D160846
It is possible to specify full names for capabilities when using the clang
thread-safety analysis which will be used in error messages. We should use that
form of the attribute rather than the legacy lockable attribute.
Differential Revision: https://phabricator.services.mozilla.com/D160531
To avoid real or apparent races to the list of marker schema functions, some
bits of the atomic count are used to effectively implement a RWLock, so that
any number of threads can add their own new marker schema concurrently, while
the profile-capture reading of the whole list can only be done on its own.
Differential Revision: https://phabricator.services.mozilla.com/D157310
When something goes wrong, the most likely cause is running out of memory, so
we clear our data to try and free some memory ASAP, to hopefully reduce the
likelihood of a terminating OOM elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D155653
Instead of redundantly explaining each `static_cast` in different
SpliceableChunkedJSONWriter functions, safe accesses are now isolated to only
two functions, making the public function implementations simpler, including
changes in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D155650
Note that at this point, it's using the FailureLatchInfallibleSource singleton,
so operations are still effectively infallible, i.e. they will terminate the
program.
But users already handle future fallible outcomes.
Differential Revision: https://phabricator.services.mozilla.com/D155649
This removes some redundant initializers in constructors (present and future).
Also some [[nodiscard]]s were added where appropriate, and empty lines for
clarity.
Differential Revision: https://phabricator.services.mozilla.com/D155648
The FailureLatch interface, and some implementation helpers and classes, will
be used to record the first failure (if any) during some long process.
Differential Revision: https://phabricator.services.mozilla.com/D155647
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Differential Revision: https://phabricator.services.mozilla.com/D154619
Most users of JSONWriter want to fill a string, so instead of having all these
similar implementations, we now have central reusable implementations:
- JSONStringWriteFunc contains a string and writes to it.
- JSONStringRefWriteFunc references a string and writes to it. This is most
useful when the string already exists somewhere, or needs to be returned from
a function (so we avoid another conversion when returning).
Differential Revision: https://phabricator.services.mozilla.com/D154618
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Differential Revision: https://phabricator.services.mozilla.com/D154617
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Depends on D154618
Differential Revision: https://phabricator.services.mozilla.com/D154619
Most users of JSONWriter want to fill a string, so instead of having all these
similar implementations, we now have central reusable implementations:
- JSONStringWriteFunc contains a string and writes to it.
- JSONStringRefWriteFunc references a string and writes to it. This is most
useful when the string already exists somewhere, or needs to be returned from
a function (so we avoid another conversion when returning).
Depends on D154617
Differential Revision: https://phabricator.services.mozilla.com/D154618
mWriter is now a reference, and the ownership is optional through a separate
member variable that could stay null.
User can now choose to keep the JSONWriteFunc on their stack, which saves a
heap allocation, and makes it easier to access the concrete JSONWriteFunc
implementation directly (instead of through WriteFunc()).
Depends on D154616
Differential Revision: https://phabricator.services.mozilla.com/D154617
mWriter is never null (and lots of calls just dereference it without checking),
so we may as well enforce it:
- The constructor MOZ_RELEASE_ASSERTs that it's not null.
- The accessor WriteFunc() returns a reference instead of a scary raw pointer.
(Note that we can't make mWriter a NotNull<...>, because the next patch will
give the option to keep that owning pointer null.)
Differential Revision: https://phabricator.services.mozilla.com/D154616
We currently support stack walking everywhere, and when it fails, we fall back
to leaf stacks. The leaf option is a bit confusing in how it works, and doesn't
provide much value.
Differential Revision: https://phabricator.services.mozilla.com/D153695
We currently support stack walking everywhere, and when it fails, we fall back
to leaf stacks. The leaf option is a bit confusing in how it works, and doesn't
provide much value.
Differential Revision: https://phabricator.services.mozilla.com/D153695
The BASE_PROFILER_DEFAULT_...ENTRIES constants in BaseProfiler.h were smaller
than those in ProfilerControl.h, leading to a shorter profiling range in the
parent process!
Now these constants and some other shared ones are only defined in
BaseProfiler.h, and reused in ProfilerControl.h.
PROFILER_DEFAULT_DURATION was moved to where it's first used, and should one
day disappear (see bug 1632365).
Differential Revision: https://phabricator.services.mozilla.com/D153669
The Wasm profiling frame iterator uses the return address in the LR register when
interrupting during the prologue. The Linux/Android code was correctly initializing it,
but on Mac and Windows we always used 0.
Differential Revision: https://phabricator.services.mozilla.com/D152268
This will be useful to see how big profiles get during gathering, and
potentially to avoid making them too big if possible.
Differential Revision: https://phabricator.services.mozilla.com/D151901
Nazım Can Altınova
Iulian Moraru
Marco Castelluccio
alwu
Michael Comella
Nika Layzell
Florian Quèze
Cristian Tuns
Paul Adenot
Butkovits Atila
Marian Laza
Mike Hommey
Gerald Squelart
Fabrice Desré
Andreea Pavel
Jan de Mooij