This patch will do :
- create a sub-category `Cubeb`
- add `Cubeb` profiling labels in related codes
The advantage of doing so :
- allow us to know the percentage of time respectively we spend on cubeb and non-cubeb codes
More details :
The profiling code would include `<atomic>` which is C++ only, so I can't use the label in `cubeb.c` directly. Instead, I add labels on the `AudioStream` and `AudioCallbackDriver` where we would call cubeb related methods.
Differential Revision: https://phabricator.services.mozilla.com/D74172
This patch will do :
- create a profiling category `Media`
- add `Media` profiling labels in related codes
The advantage of doing so :
- allow us to easily see what operations are related to media playback from the profiled report
More details :
According to the description in the `ProfilingCategory.h`, `topmost profiler label frame in the label stack determines the category pair of that stack`. Therefore, most labels I added are the first task would run on the thread, in order to ensure all its following tasks can be marked as the media playback label as well.
Differential Revision: https://phabricator.services.mozilla.com/D74171
If a label contains a dynamic string that's too long (512 characters or more), instead of just replacing it with "(too long)", we now cut it down to the maximum size, with an ellipsis at the end.
Added test for that in gtest. Also added nearby test for empty strings.
Differential Revision: https://phabricator.services.mozilla.com/D74378
Whenever chunks are about to be destroyed, we try to keep one or two alive, to hopefully fulfill the next request, thereby avoiding a deallocation+allocation pair.
Differential Revision: https://phabricator.services.mozilla.com/D72370
The chunk metadata size is tiny (less than 100 bytes) compared to the buffer size (1MB by default), so it's fine to ignore it while dealing with cross-Firefox limits.
Differential Revision: https://phabricator.services.mozilla.com/D72558
Interface class for a chunk manager that can be controlled: It will provide updates about chunks, and release chunks on command.
Differential Revision: https://phabricator.services.mozilla.com/D72362
profiler_is_locked_on_current_thread() is used to help users avoid calling `profiler_...` functions when the profiler may already have a lock in place, which would prevent a 2nd recursive lock (resulting in a crash or a never-ending wait).
So we must return `true` for any of:
- The main profiler mutex, used by most functions, and/or
- The buffer mutex, used directly in some functions without locking the main mutex, e.g., marker-related functions.
Differential Revision: https://phabricator.services.mozilla.com/D73789
Expose `ProfileChunkedBuffer`'s mutex (if present), so that potential callers can avoid recursive calls that would lock or crash.
Differential Revision: https://phabricator.services.mozilla.com/D73788
Make `BaseProfilerMutex::mOwningThreadId` non-optional, and use it in `IsLockedOnCurrentThread()`, which is similar to the one in Gecko Profiler.
Add related `BaseProfilerMaybeMutex::IsActivatedAndLockedOnCurrentThread()`.
Differential Revision: https://phabricator.services.mozilla.com/D73786
At the time this code was written, JavaScript JIT entry trampolines were
emitting EnterJIT label frames that carried a stack address. From this stack
address, register values could be recovered that would allow native stack
unwinding to resume after getting lost in JIT code.
The EnterJIT label frame was removed in bug 1057082.
Differential Revision: https://phabricator.services.mozilla.com/D73939
I apologize for mixing multiple types of changes in this patch. The mix is probably harder to review than necessary.
Because of the way these .cpp files are listed in mozglue/baseprofiler/moz.build,
they are only built when MOZ_GECKO_PROFILER is set. So the #ifdef MOZ_GECKO_PROFILER
wrapper is now unnecessary.
Removing this wrapper has many knock-on effects on other lines in these files
due to preprocessor line indentation.
As I was removing the #ifdefs, I was reordering includes as well, to follow the
include order laid out on https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes ;
namely, system headers should go before "your project's" .h files.
I also removed the BaseProfiler.h include from some files but not from all.
In the past, the BaseProfiler.h include served the purpose of picking up the
MOZ_BASE_PROFILER #define, and it's no longer needed for that reason.
There are probably lots of now-unnecessary BaseProfiler.h includes left.
Differential Revision: https://phabricator.services.mozilla.com/D73527
The profiler can be given any power of two, but there were no safety checks to ensure that the buffer had a minimum workable capacity (to hold at least 4 chunks, each capable of holding at least one stack sample), and also to prevent large buffers that could break the currently-supported 2GiB limit.
This fixes the issue with test_merged_stacks.js, which was requesting a too-small buffer. (This started when we switched to the chunk-based buffer, because the profiler was blindly using the provided number as maximum, and dividing that size by 4 for each chunk, which was not enough to hold a full sample in some builds.)
Differential Revision: https://phabricator.services.mozilla.com/D73212
This is how my mapfile looks like:
5587df936000-5587df96b000 r--p 00000000 fd:02 21584889 /home/emilio/src/moz/gecko/obj-debug/dist/bin/firefox
5587df96b000-5587df9ec000 r-xp 00035000 fd:02 21584889 /home/emilio/src/moz/gecko/obj-debug/dist/bin/firefox
5587df9ec000-5587df9ed000 r--p 000b6000 fd:02 21584889 /home/emilio/src/moz/gecko/obj-debug/dist/bin/firefox
5587df9ed000-5587df9ee000 rw-p 000b7000 fd:02 21584889 /home/emilio/src/moz/gecko/obj-debug/dist/bin/firefox
Note how the executable bit, which is the only one we look at, and which
is where we get exeExeAddr from (0x5587df96b000 in this case) is in the
middle of the executable, but the library will span all four ranges.
Check for whether the library _contains_ the start address of the
executable region instead of whether it starts with it.
Differential Revision: https://phabricator.services.mozilla.com/D72504
As opposed to `ProfileBufferIndex` (no "Block"), `ProfileBufferBlockIndex` is only supposed to point at a valid block start.
If we trust this assumption, it allows for quick access to the given block index inside the buffer, as we don't need to read blocks one by one until we reach the given position.
There are still safety checks (MOZ_ASSERTs in DEBUG builds) to verify that block indices are correctly used.
Differential Revision: https://phabricator.services.mozilla.com/D71502
Renamed some variables to be more generic. Their type is going to change in the next patch, and that type doesn't need to be in the names; also it will make the next patch easier to review.
Differential Revision: https://phabricator.services.mozilla.com/D71882
`explicit operator bool()` and `operator!()` were cute ways to make `InChunkBuffer` quack like a pointer when testing if it's effectively null.
But after some experience, and since `InChunkPointer` will not be used in generic code where pointers would be accepted, I now think that it's better to be clearer about it and use an explicit `IsNull()`.
Differential Revision: https://phabricator.services.mozilla.com/D71499
Same as with `BlocksRingBuffer`: Instead of a potentially-null pointer to a
`ProfileBufferEntryWriter`, we are now providing a
`Maybe<ProfileBufferEntryWriter>`, which is safer.
Differential Revision: https://phabricator.services.mozilla.com/D71287
Instead of a potentially-null pointer to a `ProfileBufferEntryWriter`, we are now providing a `Maybe<ProfileBufferEntryWriter>`, which is safer.
Differential Revision: https://phabricator.services.mozilla.com/D71286
This is needed to embed a small buffer (e.g., containing one backtrace attached
to a marker) into a bigger buffer (e.g., the main profiler buffer).
Differential Revision: https://phabricator.services.mozilla.com/D69499
--HG--
extra : moz-landing-system : lando
`InChunkPointer` is an internal accessor pointing at a position inside a chunk.
It can handle up to two groups of chunks (typically the extant chunks stored in
the chunk manager, and the current chunk.
Differential Revision: https://phabricator.services.mozilla.com/D69497
--HG--
extra : moz-landing-system : lando
To ensure that a spare chunk is ready to handle data that will eventually
overflow the current chunk, `ProfileChunkedBuffer` uses
`ProfileBufferChunk::RequestChunk()` to queue a request for a new chunk.
This request should be handled off-thread by the buffer user -- but a response
is not guaranteed, so the buffer does not rely on it and can get a new chunk
on the spot if really needed.
Because the request is asynchronous, and because either the buffer or the user
could be destroyed while a request is in flight, a shared
`RequestedChunkRefCountedHolder` object is used:
- When the request is handled, the new chunk (or nullptr) is given to the
holder.
- When the buffer needs a new chunk, it can retrieve the new chunk if the
request was successfully fulfilled.
If the requestee is destroyed first, the request won't be fulfilled and the
buffer will carry on without relying on requests.
If the requester is destroyed first, the holder (with a potential requested
chunk) will just get destroyed after the request is fulfilled or the requestee
is destroyed as well.
Differential Revision: https://phabricator.services.mozilla.com/D69495
--HG--
extra : moz-landing-system : lando
`ProfileChunkedBuffer` can handle zero or one `ProfileBufferChunkManager` at a
time, and can optionally take ownership of the manager.
Differential Revision: https://phabricator.services.mozilla.com/D69494
--HG--
extra : moz-landing-system : lando
ProfileChunkedBuffer simulates a near-infinite buffer over ProfileBufferChunks.
It uses a ProfileBufferChunkManager to get chunks and later release them.
Its use is similar to BlocksRingBuffer:
- It reserves blocks in chunks, adds some structure (just the size of the entry
that follows), and lets a user-provided writer write the entry.
- It allows reading past entries.
- It can be in an "out-of-session" state where APIs are still available but do
nothing.
It is intended to eventually replace BlocksRingBuffer.
This patch starts with the basic structure, following patches will add all
planned features.
Differential Revision: https://phabricator.services.mozilla.com/D69493
--HG--
extra : moz-landing-system : lando
`ProfileBuffer` used to check if a `BlocksRingBuffer` was in session by looking
at its buffer size.
Now `IsInSession()` should be used, it is clearer in intent, and will make the
transition to `ProfileChunkedBuffer` slightly easier.
Differential Revision: https://phabricator.services.mozilla.com/D69492
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's attribute((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
And removed a few unneded `#include "mozilla/Attributes.h"`.
Differential Revision: https://phabricator.services.mozilla.com/D69755
--HG--
extra : moz-landing-system : lando
`ProfileBufferChunkManagerWithLocalLimit` is a chunk manager that enforces a
memory limit in each process.
It is meant to mimic the main way `BlocksRingBuffer` works, so that we can more
easily switch to the new buffer storage without introducing the extra complexity
of inter-process memory coordination yet.
`ProfileBufferChunkManagerWithLocalLimit` will still offer a benefit over
`BlocksRingBuffer`, in that it won't allocate the maximum buffer size
immediately -- speeding the initialization, and hopefully even reducing the
total Firefox memory consumption in short-lived processes.
Differential Revision: https://phabricator.services.mozilla.com/D68770
--HG--
extra : moz-landing-system : lando
We still need it for Android < 6.0 (API 23) because otherwise we don't
have a way to hook up mozalloc.
Differential Revision: https://phabricator.services.mozilla.com/D66993
--HG--
extra : moz-landing-system : lando
A `ProfileBufferChunk` represents a single chunk of memory, with an optional
link to the next chunk.
In the new Fission-compatible profiler storage, chunks will be allocated by a
chunk manager, filled with data by the profiler, and then released back to the
chunk manager.
The chunk manager may decide to destroy or recycle old chunks based on memory
limits (per process, or for the entire Firefox app).
Differential Revision: https://phabricator.services.mozilla.com/D67272
--HG--
extra : moz-landing-system : lando
A `ProfileBufferChunk` represents a single chunk of memory, with an optional
link to the next chunk.
In the new Fission-compatible profiler storage, chunks will be allocated by a
chunk manager, filled with data by the profiler, and then released back to the
chunk manager.
The chunk manager may decide to destroy or recycle old chunks based on memory
limits (per process, or for the entire Firefox app).
Differential Revision: https://phabricator.services.mozilla.com/D67272
--HG--
extra : moz-landing-system : lando
We still need it for Android < 6.0 (API 23) because otherwise we don't
have a way to hook up mozalloc.
Differential Revision: https://phabricator.services.mozilla.com/D66993
--HG--
extra : moz-landing-system : lando
The old code was using `std::index_sequence_for` to call templated functions for
*every* possible Variant alternative.
Instead, using `Variant::match()` with a generic lambda (that also takes the
current Variant index, thanks to bug 1621865) means we're only calling the
function corresponding to the current alternative.
Differential Revision: https://phabricator.services.mozilla.com/D67241
--HG--
extra : moz-landing-system : lando
Stop including "Linker.h" and always include <link.h> instead, which also comes with ElfW() and other things that this code needs.
Also fix up "!/" path detection code.
Differential Revision: https://phabricator.services.mozilla.com/D64997
--HG--
extra : moz-landing-system : lando
This fixes the declaration of (BaseProfiler)LogTest. It also makes it so that the logs show up on Android.
In xpcom we have printf_stderr which does something similar and also handles Windows.
Differential Revision: https://phabricator.services.mozilla.com/D64994
--HG--
extra : moz-landing-system : lando
This removes most dependencies on BlocksRingBuffer, to ease the transition to
the upcoming Fission-friendly profile buffer, including:
- Length type,
- SumBytes(),
- Gecko extensions of serialization.
Differential Revision: https://phabricator.services.mozilla.com/D66722
--HG--
rename : tools/profiler/public/BlocksRingBufferGeckoExtensions.h => tools/profiler/public/ProfileBufferEntrySerializationGeckoExtensions.h
extra : moz-landing-system : lando
Fold expressions are more expressive and probably produce better code than the
older template-recursion and initializer_list patterns.
Differential Revision: https://phabricator.services.mozilla.com/D66535
--HG--
extra : moz-landing-system : lando
When we are running from a network drive the new feature in part 1 doesn't work.
So this uses DuplicateHandle instead of OpenThread to get the thread handle used
by the profiler.
It also removes a DuplicateHandle THREAD_ALL_ACCESS call that also fails and a
DuplicateHandle to get a real process handle, which only seems to have been to
fix something on Windows XP.
The handle passed in is always the profiler one, so already has the necessary
permissions. If no thread handle is passed then the pseudo handle is used.
Differential Revision: https://phabricator.services.mozilla.com/D66611
--HG--
extra : moz-landing-system : lando
When we are running from a network drive the new feature in part 1 doesn't work.
So this uses DuplicateHandle instead of OpenThread to get the thread handle used
by the profiler.
It also removes a DuplicateHandle THREAD_ALL_ACCESS call that also fails and a
DuplicateHandle to get a real process handle, which only seems to have been to
fix something on Windows XP.
The handle passed in is always the profiler one, so already has the necessary
permissions. If no thread handle is passed then the pseudo handle is used.
Depends on D66610
Differential Revision: https://phabricator.services.mozilla.com/D66611
--HG--
extra : moz-landing-system : lando
The new ProfileBufferEntryReader/Writer are now used everywhere, including in
the profilers and tests.
The old EntryReader/Writer have been removed.
Differential Revision: https://phabricator.services.mozilla.com/D65697
--HG--
extra : moz-landing-system : lando
Actual implementation of the entry reader and writer.
They expose a very similar API as the original BlocksRingBuffer entry reader&
writer.
(No tests here; In the next patch they will get used instead of the old reader&
writer, and will hence inherit all relevant tests.)
Differential Revision: https://phabricator.services.mozilla.com/D65696
--HG--
extra : moz-landing-system : lando
ProfileBufferEntrySerialization.h will contain the entry reader and writer.
This patch creates the file with renamed copies of the (de)serializers from
BlocksRingBuffer; there shouldn't be significant code changes, this `hg cp` will
help keep their history. See next patch for how they will actually be used.
Differential Revision: https://phabricator.services.mozilla.com/D65695
--HG--
rename : mozglue/baseprofiler/public/BlocksRingBuffer.h => mozglue/baseprofiler/public/ProfileBufferEntrySerialization.h
extra : moz-landing-system : lando
To facilitate the upcoming transition to a new Fission-friendly storage, all
uses of `BlocksRingBuffer::{,Block}Index` are replaced with
`ProfileBuffer{,Block}Index`.
`BlocksRingBuffer::{,Block}Index` are not needed anymore.
Differential Revision: https://phabricator.services.mozilla.com/D64516
--HG--
extra : moz-landing-system : lando
ProfileBufferIndex.h contains:
- `ProfileBufferIndex`, a generic index into a Profiler buffer.
- `ProfileBufferBlockIndex`, an almost-opaque index that should only point at
valid (or expired) blocks.
These will soon be used instead of `BlocksRingBuffer::{,Block}Index`, to make
the transition away from `BlocksRingBuffer` easier.
Differential Revision: https://phabricator.services.mozilla.com/D64515
--HG--
extra : moz-landing-system : lando
Some of the BaseProfile headers are always available, even when BaseProfiler
itself is not built, so we should test these in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D63230
--HG--
extra : moz-landing-system : lando
Some of the BaseProfile headers are always available, even when BaseProfiler
itself is disabled, so we should test these in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D63230
--HG--
extra : moz-landing-system : lando
This makes Gecko build again. I'll squash this into the previous commit anyhow.
Differential Revision: https://phabricator.services.mozilla.com/D60324
--HG--
extra : moz-landing-system : lando
Now both profilers are controlled by the same environment variables, e.g.
"MOZ_PROFILER_STARTUP" to run both profilers at startup.
The only remaining Base Profiler-specific commands are:
- MOZ_BASE_PROFILER_HELP, because the Base Profiler doesn't have the same
capabilities as Gecko, so it may display different available features.
- MOZ_BASE_PROFILER_LOGGING, because the Base Profiler doesn't have access to
MOZ_LOG (both the env-var and the C++ macros).
Differential Revision: https://phabricator.services.mozilla.com/D54449
--HG--
extra : moz-landing-system : lando
This env-vars were not processed because of some needed special processing, and
they were not critical.
But now we want them to be correctly read, to match the Gecko Profiler features.
Differential Revision: https://phabricator.services.mozilla.com/D54448
--HG--
extra : moz-landing-system : lando
In bug 1587332, ActivePS::mProfileBuffer was changed from
`const UniquePtr<ProfileBuffer>` to just `ProfileBuffer`, so its own object size
is now counted as part of `sizeof(ActivePS)`, and we should only count its
dependencies with `SizeOfExcludingThis`.
Differential Revision: https://phabricator.services.mozilla.com/D58288
--HG--
extra : moz-landing-system : lando
The only way to select all registered threads was to have an empty entry in the
filter list, usually by just having "," (a single comma).
The popup removes spurious empty items, making this impossible for most users.
It is now possible to just have "*" (as the whole filter string, or at least one
item in the list) to select all registered threads.
Differential Revision: https://phabricator.services.mozilla.com/D57594
--HG--
extra : moz-landing-system : lando
This is especially useful when debugging both Base Profiler and Gecko Profiler,
so that their messages are correctly sequenced.
Differential Revision: https://phabricator.services.mozilla.com/D54447
--HG--
extra : moz-landing-system : lando
The Base Profiler originally named the main thread "Main Thread", which is
friendlier than "GeckoMain". However this makes it more difficult to combine the
controls for both profilers if they use different names.
So now both profilers use "GeckoMain", so filters can be exactly the same.
Base Profiler adds "(pre-xul)" to the name to distinguish tracks in the
frontend -- This distinction is actually necessary so the frontend doesn't get
confused by threads with the exact same name, but eventually tracks will get
combined in the frontend as well.
Differential Revision: https://phabricator.services.mozilla.com/D54444
--HG--
extra : moz-landing-system : lando
This is especially useful when debugging both Base Profiler and Gecko Profiler,
so that their messages are correctly sequenced.
Differential Revision: https://phabricator.services.mozilla.com/D54447
--HG--
extra : moz-landing-system : lando
The Base Profiler originally named the main thread "Main Thread", which is
friendlier than "GeckoMain". However this makes it more difficult to combine the
controls for both profilers if they use different names.
So now both profilers use "GeckoMain", so filters can be exactly the same.
Base Profiler adds "(pre-xul)" to the name to distinguish tracks in the
frontend -- This distinction is actually necessary so the frontend doesn't get
confused by threads with the exact same name, but eventually tracks will get
combined in the frontend as well.
Differential Revision: https://phabricator.services.mozilla.com/D54444
--HG--
extra : moz-landing-system : lando
For now, there is no flag to actually allow it, but this is the
code-side changes to allow the linker being disabled.
Differential Revision: https://phabricator.services.mozilla.com/D54074
--HG--
extra : moz-landing-system : lando
The custom linker used on Android (FaultyLib), can be enabled on
non-Android, and in the near future, may not always be enabled on
Android, so the FaultyLib-specific parts of the profile need to not be
specific to Android, but to the linker being enabled instead.
Differential Revision: https://phabricator.services.mozilla.com/D54073
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
We want the profiler UI to be able to know if the data can be used for
reconstructing the event delays, since it measures something different
from the old 16ms event injection.
Differential Revision: https://phabricator.services.mozilla.com/D52534
--HG--
extra : moz-landing-system : lando
We want the profiler UI to be able to know if the data can be used for
reconstructing the event delays, since it measures something different
from the old 16ms event injection.
Differential Revision: https://phabricator.services.mozilla.com/D52534
--HG--
extra : moz-landing-system : lando
Avoids deadlocks on Windows due to Now() taking a lock; if done while we've
paused a thread that holds the lock we will deadlock.
Differential Revision: https://phabricator.services.mozilla.com/D52392
--HG--
extra : moz-landing-system : lando
profile.counters[n].sample_groups was mistakenly streamed as an object, which
prevents having more than one, and goes against the published format
documentation.
The front-end was implemented to process the incorrect format, so it will need
to be updated as well; hence the version change to 18.
Differential Revision: https://phabricator.services.mozilla.com/D49867
--HG--
extra : moz-landing-system : lando
Having `mProfileBuffer` be a pointer is not really helpful:
- The pointer is never null (It's allocated on ActivePS construction, and
implicitly deleted on ActivePS destruction); it's never moved-from.
- It requires an extra `new` and an extra `delete`.
Differential Revision: https://phabricator.services.mozilla.com/D48650
--HG--
extra : moz-landing-system : lando
Add assertions that all `sInstance` pointers (from both `CorePS` and `ActivePS`)
are not null before being dereferenced.
This is probably more than needed, but it's only `MOZ_ASSERT`s limited to
Nightly, and it should give better feedback in case something goes wrong.
Eventually, I think it would be better to make most methods non-static, and have
a checked reference-to-instance getter.
Differential Revision: https://phabricator.services.mozilla.com/D48649
--HG--
extra : moz-landing-system : lando
We are not simply excluding all about:blanks because there might be some
about:blank that user really visits. But for others we don't want to include
the first about:blank because when a BrowsingContext is loaded, and if the
principal matches, the first document loaded in it will share the inner window.
Differential Revision: https://phabricator.services.mozilla.com/D47067
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
Previously, the absence of "stackwalk", "leaf", and "javascript" implied that
the test/user didn't want any sampling, but this caused issues in some tests
that enabled "stackwalk" on platforms that didn't support stack-walking, which
ended up suppressing label-only stacks that the test expected.
we now have an explicit feature "nostacksampling" that disables backtraces from
the samplers in both profilers. This effectively cancels "stackwalk", "leaf",
and "javascript" if present.
Differential Revision: https://phabricator.services.mozilla.com/D47731
--HG--
extra : moz-landing-system : lando
Previously, the absence of "stackwalk", "leaf", and "javascript" implied that
the test/user didn't want any sampling, but this caused issues in some tests
that enabled "stackwalk" on platforms that didn't support stack-walking, which
ended up suppressing label-only stacks that the test expected.
we now have an explicit feature "nostacksampling" that disables backtraces from
the samplers in both profilers. This effectively cancels "stackwalk", "leaf",
and "javascript" if present.
Differential Revision: https://phabricator.services.mozilla.com/D47731
--HG--
extra : moz-landing-system : lando
`BlocksRingBuffer` had an "entry destructor" to make it a more generic
container, and it was useful during early prototyping of the new profiler
storage (so that we could store owning pointers).
But this entry destructor is stored in an `std::function`, which gets marked as
a potential GC caller by the js rooting hazard analyzer; and as this bug found,
it's not obvious where to place `JS::AutoSuppressGCAnalysis`, because profiler
entries (including stacks) could be added on one thread while GC happens
elsewhere, which triggers the embedded `AutoAssertNoGC` check.
Since we don't actually use the entry destructor facility in the profiler, it's
easier to just get rid of it. As a bonus, it's a small optimization.
Tests that were using an entry destructor now use the `State` instead, to verify
that entries are pushed and cleared as expected.
If needed in the future outside of the profiler, `BlocksRingBuffer` could again
include an entry destructor, but it would have to be through templating, so that
the class used in the profiler wouldn't contain an `std::function`.
Differential Revision: https://phabricator.services.mozilla.com/D46738
--HG--
extra : moz-landing-system : lando
In some situations, entries may in fact take more than half the buffer size
(e.g., when duplicating a stack into a small temporary buffer).
So we now allow blocks to take the full buffer size -- but not more, as they
would start overwriting themselves!
Differential Revision: https://phabricator.services.mozilla.com/D46453
--HG--
extra : moz-landing-system : lando
Instead of copying `BlocksRingBuffer` data byte-by-byte (using iterators byte
dereferencers), we can now use `ModuloBuffer::Iterator::ReadInto(Iterator&)` to
copy them using a small number of `memcpy`s.
Differential Revision: https://phabricator.services.mozilla.com/D45839
--HG--
extra : moz-landing-system : lando
Some objects are copied byte-by-byte to/from `ModuloBuffer`s.
E.g., serialized `BlocksRingBuffer`s, or duplicate stacks. (And more to come.)
`Iterator::ReadInto(Iterator&)` optimizes these copies by using the minimum
number of `memcpy`s possible.
Differential Revision: https://phabricator.services.mozilla.com/D45838
--HG--
extra : moz-landing-system : lando
profiler_can_accept_markers() is a fast and racy check that markers would
currently be stored, it should be used around potentially-expensive calls to
add markers.
And now markers are no longer stored when the profiler is paused. (Note that the
profiler is paused when a profile is being stored, this will help make this
operation faster.)
Differential Revision: https://phabricator.services.mozilla.com/D44434
--HG--
extra : moz-landing-system : lando
Since all profiler data is now stored inside ProfileBuffer, there is no real
need to continuously discard old data during sampling (this was particularly
useful to reclaim memory taken by old markers&payloads).
Instead, we can now just discard the old data once, just before starting to
stream it to JSON.
Differential Revision: https://phabricator.services.mozilla.com/D44433
--HG--
extra : moz-landing-system : lando
Now that what was in ProfilerMarker is stored directly in `BlocksRingBuffer`,
there is no need for this class anymore!
This also removes all the pointer management around it (when added to a TLS
list, moved during sampling, deleted when expired).
Differential Revision: https://phabricator.services.mozilla.com/D43431
--HG--
extra : moz-landing-system : lando
Since payloads are not kept alive long after they have been serialized, we can
just create them on the stack and pass a reference to their base (or pointer,
`nullptr` representing "no payloads") to `profiler_add_marker()`.
Differential Revision: https://phabricator.services.mozilla.com/D43430
--HG--
extra : moz-landing-system : lando
Markers and their payloads can now be serialized straight into the profiler's
`BlocksRingBuffer`, which is now thread-safe to allow such concurrent accesses
(even when gPSMutex is not locked).
This already saves us from having to allocate a `PayloadMarker` on the heap, and
from having to manage it in different lists.
The now-thread-safe `BlocksRingBuffer` in `CorePS` cannot be used inside the
critical section of `SamplerThread::Run`, because any mutex function could hang
because of the suspended thread (even though they functionally don't appear to
interact). So the sampler now uses a local `BlocksRingBuffer` without mutex.
As a bonus, the separate buffer helps reduce the number of concurrent locking
operations needed when capturing the stack.
Differential Revision: https://phabricator.services.mozilla.com/D43429
--HG--
extra : moz-landing-system : lando
Copy the full contents of BlocksRingBuffer into another one.
This is mainly useful to use a temporary buffer to store some data without
contentions, and then integrate the temporary buffer into the main one.
Differential Revision: https://phabricator.services.mozilla.com/D45306
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
The common data members stored in the ProfilerMarkerPayload base class can be
gathered into a struct, which will make it easier to pass around, especially
when a derived object is constructed with these common properties.
Differential Revision: https://phabricator.services.mozilla.com/D43427
--HG--
extra : moz-landing-system : lando
Markers may contain backtraces, so we need to be able to de/serialize them.
This involves de/serializing the underyling `BlocksRingBuffer`.
Differential Revision: https://phabricator.services.mozilla.com/D43426
--HG--
extra : moz-landing-system : lando
The main `BlocksRingBuffer`s will be stored in `CorePS` (outside of
`ProfileBuffer`s), as we need to be able to safely access the underlying buffers
when profilers are not enabled.
Also `ProfilerBacktrace` will own the `BlocksRingBuffer` that its captured
`ProfileBuffer` uses.
Taking this opportunity to rename the different `mBuffer`s to more useful names.
Differential Revision: https://phabricator.services.mozilla.com/D43422
--HG--
extra : moz-landing-system : lando
Now that we are using a byte-oriented `BlocksRingBuffer` instead of an array of
9-byte `ProfileBufferEntry`'s, internally the profiler sets the buffer size in
bytes. However all external users (popup, tests, etc.) still assume that the
requested capacity is in entries!
To limit the amount of changes, we will keep assuming externally-visible
capacities are in entries, and convert them to bytes.
Even though entries used to be 9 bytes each, and `BlocksRingBuffer` adds 1 byte
for the entry size, some entries actually need less space (e.g., 32-bit numbers
now take 6 bytes instead of 9), so converting to less than 9 bytes per entry is
acceptable.
We are settling on 8 bytes per entry: It's close to 9, and it's a power of two;
since the effective number of entries was a power of two, and `BlocksRingBuffer`
also uses a power of two size in bytes, this convertion keeps sizes in powers of
two.
Differential Revision: https://phabricator.services.mozilla.com/D44953
--HG--
extra : moz-landing-system : lando
This just replaces `ProfileBuffer`'s self-managed circular buffer with a
`BlocksRingBuffer`.
That `BlocksRingBuffer` does not need its own mutex (yet), because all uses go
through gPSMutex-guarded code.
`ProfileBuffer` now also pre-allocates a small buffer for use in
`DuplicateLastSample()`, this avoids multiple mallocs at each sleeping thread
stack duplication.
Note: Internal "magic" sizes have been multiplied by 8 (and tweaked upwards, to
handle bigger stacks), because they originally were the number of 9-byte
entries, but now it's the buffer size in bytes. (And entries can now be smaller
than 9 bytes, so overall the capacity in entries should be similar or better.)
However, external calls still think they are giving a number of "entries", this
will be handled in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D43421
--HG--
extra : moz-landing-system : lando
Add some stats (off by default) around streaming JSON, as the following patches
may affect it.
Differential Revision: https://phabricator.services.mozilla.com/D44952
--HG--
extra : moz-landing-system : lando
In some situations we will *need* to use a `BlocksRingBuffer` that absolutely
does not use a mutex -- In particular in the critical section of
`SamplerThread::Run()`, when a thread is suspended, because any action on any
mutex (even a private one that no-one else interacts with) can result in a hang.
As a bonus, `BlocksRingBuffer`s that are known not to be used in multi-thread
situations (e.g., backtraces, extracted stacks for duplication, etc.) will waste
less resources trying to lock/unlock their mutex.
Differential Revision: https://phabricator.services.mozilla.com/D45305
--HG--
extra : moz-landing-system : lando
`BaseProfilerMaybeMutex` wraps a `BaseProfilerMutex` inside a `Maybe`.
The decision to use a mutex or not is set at construction time.
If there is no mutex, all operations do nothing (at the small cost of checking
if the mutex is present.)
`BaseProfilerMaybeAutoLock` is the recommented RAII object to lock and
automatically unlock a `BaseProfilerMaybeMutex` until the end of a block scope.
Differential Revision: https://phabricator.services.mozilla.com/D45304
--HG--
extra : moz-landing-system : lando
Instead of copying `BlocksRingBuffer` data byte-by-byte (using iterators byte
dereferencers), we can now use `ModuloBuffer::Iterator::ReadInto(Iterator&)` to
copy them using a small number of `memcpy`s.
Differential Revision: https://phabricator.services.mozilla.com/D45839
--HG--
extra : moz-landing-system : lando
Some objects are copied byte-by-byte to/from `ModuloBuffer`s.
E.g., serialized `BlocksRingBuffer`s, or duplicate stacks. (And more to come.)
`Iterator::ReadInto(Iterator&)` optimizes these copies by using the minimum
number of `memcpy`s possible.
Differential Revision: https://phabricator.services.mozilla.com/D45838
--HG--
extra : moz-landing-system : lando
profiler_can_accept_markers() is a fast and racy check that markers would
currently be stored, it should be used around potentially-expensive calls to
add markers.
And now markers are no longer stored when the profiler is paused. (Note that the
profiler is paused when a profile is being stored, this will help make this
operation faster.)
Differential Revision: https://phabricator.services.mozilla.com/D44434
--HG--
extra : moz-landing-system : lando
Since all profiler data is now stored inside ProfileBuffer, there is no real
need to continuously discard old data during sampling (this was particularly
useful to reclaim memory taken by old markers&payloads).
Instead, we can now just discard the old data once, just before starting to
stream it to JSON.
Differential Revision: https://phabricator.services.mozilla.com/D44433
--HG--
extra : moz-landing-system : lando
Now that what was in ProfilerMarker is stored directly in `BlocksRingBuffer`,
there is no need for this class anymore!
This also removes all the pointer management around it (when added to a TLS
list, moved during sampling, deleted when expired).
Differential Revision: https://phabricator.services.mozilla.com/D43431
--HG--
extra : moz-landing-system : lando
Since payloads are not kept alive long after they have been serialized, we can
just create them on the stack and pass a reference to their base (or pointer,
`nullptr` representing "no payloads") to `profiler_add_marker()`.
Differential Revision: https://phabricator.services.mozilla.com/D43430
--HG--
extra : moz-landing-system : lando
Markers and their payloads can now be serialized straight into the profiler's
`BlocksRingBuffer`, which is now thread-safe to allow such concurrent accesses
(even when gPSMutex is not locked).
This already saves us from having to allocate a `PayloadMarker` on the heap, and
from having to manage it in different lists.
The now-thread-safe `BlocksRingBuffer` in `CorePS` cannot be used inside the
critical section of `SamplerThread::Run`, because any mutex function could hang
because of the suspended thread (even though they functionally don't appear to
interact). So the sampler now uses a local `BlocksRingBuffer` without mutex.
As a bonus, the separate buffer helps reduce the number of concurrent locking
operations needed when capturing the stack.
Differential Revision: https://phabricator.services.mozilla.com/D43429
--HG--
extra : moz-landing-system : lando
Copy the full contents of BlocksRingBuffer into another one.
This is mainly useful to use a temporary buffer to store some data without
contentions, and then integrate the temporary buffer into the main one.
Differential Revision: https://phabricator.services.mozilla.com/D45306
--HG--
extra : moz-landing-system : lando
Payloads will serialize themselves into a `BlocksRingBuffer` entry when first
captured.
Later they will be deserialized, to stream JSON for the output profile.
Differential Revision: https://phabricator.services.mozilla.com/D43428
--HG--
extra : moz-landing-system : lando
The common data members stored in the ProfilerMarkerPayload base class can be
gathered into a struct, which will make it easier to pass around, especially
when a derived object is constructed with these common properties.
Differential Revision: https://phabricator.services.mozilla.com/D43427
--HG--
extra : moz-landing-system : lando
Markers may contain backtraces, so we need to be able to de/serialize them.
This involves de/serializing the underyling `BlocksRingBuffer`.
Differential Revision: https://phabricator.services.mozilla.com/D43426
--HG--
extra : moz-landing-system : lando
The main `BlocksRingBuffer`s will be stored in `CorePS` (outside of
`ProfileBuffer`s), as we need to be able to safely access the underlying buffers
when profilers are not enabled.
Also `ProfilerBacktrace` will own the `BlocksRingBuffer` that its captured
`ProfileBuffer` uses.
Taking this opportunity to rename the different `mBuffer`s to more useful names.
Differential Revision: https://phabricator.services.mozilla.com/D43422
--HG--
extra : moz-landing-system : lando
Now that we are using a byte-oriented `BlocksRingBuffer` instead of an array of
9-byte `ProfileBufferEntry`'s, internally the profiler sets the buffer size in
bytes. However all external users (popup, tests, etc.) still assume that the
requested capacity is in entries!
To limit the amount of changes, we will keep assuming externally-visible
capacities are in entries, and convert them to bytes.
Even though entries used to be 9 bytes each, and `BlocksRingBuffer` adds 1 byte
for the entry size, some entries actually need less space (e.g., 32-bit numbers
now take 6 bytes instead of 9), so converting to less than 9 bytes per entry is
acceptable.
We are settling on 8 bytes per entry: It's close to 9, and it's a power of two;
since the effective number of entries was a power of two, and `BlocksRingBuffer`
also uses a power of two size in bytes, this convertion keeps sizes in powers of
two.
Differential Revision: https://phabricator.services.mozilla.com/D44953
--HG--
extra : moz-landing-system : lando
This just replaces `ProfileBuffer`'s self-managed circular buffer with a
`BlocksRingBuffer`.
That `BlocksRingBuffer` does not need its own mutex (yet), because all uses go
through gPSMutex-guarded code.
`ProfileBuffer` now also pre-allocates a small buffer for use in
`DuplicateLastSample()`, this avoids multiple mallocs at each sleeping thread
stack duplication.
Note: Internal "magic" sizes have been multiplied by 8 (and tweaked upwards, to
handle bigger stacks), because they originally were the number of 9-byte
entries, but now it's the buffer size in bytes. (And entries can now be smaller
than 9 bytes, so overall the capacity in entries should be similar or better.)
However, external calls still think they are giving a number of "entries", this
will be handled in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D43421
--HG--
extra : moz-landing-system : lando
Add some stats (off by default) around streaming JSON, as the following patches
may affect it.
Differential Revision: https://phabricator.services.mozilla.com/D44952
--HG--
extra : moz-landing-system : lando
In some situations we will *need* to use a `BlocksRingBuffer` that absolutely
does not use a mutex -- In particular in the critical section of
`SamplerThread::Run()`, when a thread is suspended, because any action on any
mutex (even a private one that no-one else interacts with) can result in a hang.
As a bonus, `BlocksRingBuffer`s that are known not to be used in multi-thread
situations (e.g., backtraces, extracted stacks for duplication, etc.) will waste
less resources trying to lock/unlock their mutex.
Differential Revision: https://phabricator.services.mozilla.com/D45305
--HG--
extra : moz-landing-system : lando
`BaseProfilerMaybeMutex` wraps a `BaseProfilerMutex` inside a `Maybe`.
The decision to use a mutex or not is set at construction time.
If there is no mutex, all operations do nothing (at the small cost of checking
if the mutex is present.)
`BaseProfilerMaybeAutoLock` is the recommented RAII object to lock and
automatically unlock a `BaseProfilerMaybeMutex` until the end of a block scope.
Differential Revision: https://phabricator.services.mozilla.com/D45304
--HG--
extra : moz-landing-system : lando
Gather stats for most calls to `profiler_add_marker()`, including the time to
allocate payloads if any.
Differential Revision: https://phabricator.services.mozilla.com/D43420
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
Bug 1556993 fixed the crash in PoisonIOInterposer (due to missing stdout&stderr
fd's), bug 1559379 fixed the mozglue memory issue that the unit test
experienced, and this patch also includes a fix for the test failure in
browser_checkdllblockliststate.js.
So now Base Profiler can be enabled by default on Windows, still using
`MOZ_BASE_PROFILER_...` env-vars for now (upcoming bug will merge these with
non-BASE env-vars soon).
Differential Revision: https://phabricator.services.mozilla.com/D44091
--HG--
extra : moz-landing-system : lando
Use AUTO_PROFILER_STATS in both profilers, in:
- SamplerThread::Run() calling DoPeriodicSample()
- racy_profiler_add_marker
- ProfileBuffer::DeleteExpiredStoredMarkers()
This should cover all areas affected by the upcoming changes to the
ProfileBuffer storage, and how markers are stored.
Differential Revision: https://phabricator.services.mozilla.com/D42826
--HG--
extra : moz-landing-system : lando
AUTO_PROFILER_STATS(name) can be used to time a {block}.
Statistics are gathered in a function-static variable, and printf'd when the
program ends.
Differential Revision: https://phabricator.services.mozilla.com/D42825
--HG--
extra : moz-landing-system : lando
Some users will want to lock the buffer but not do any specific operation with
it.
Differential Revision: https://phabricator.services.mozilla.com/D42824
--HG--
extra : moz-landing-system : lando
Backtraces (that are kept in some marker payloads) are stored in a small
ProfileBuffer, we will need to store that data, which will happen to be inside
a BlockRingBuffer, so BlockRingBuffer needs to be able to (de)serialize itself!
This is done by storing the contents in the active buffer range, and some extra
data, to later reconstruct a BlocksRingBuffer that looks like the original.
Depends on D42496
Differential Revision: https://phabricator.services.mozilla.com/D42634
--HG--
extra : moz-landing-system : lando
Markers and their payloads contain all kinds of objects that we'll need to
serialize into a BlocksRingBuffer (new ProfileBuffer storage).
This patch will add functions to:
- Compute the size needed to store objects,
- Write multiple objects into a BlockRingBuffer entry,
- Read objects back from an entry.
And it will provide a number of useful de/serialization helpers for:
- Trivially-copyable objects,
- Strings of different types,
- Raw pointers (with some safety guards to avoid surprises),
- Tuples (to store multiple sub-objects),
- Spans,
- Maybe (for optional objects),
- Variant.
This should be enough to store most kinds of data. Further specializations
can&will be written as necessary for more complex or obscure types.
Differential Revision: https://phabricator.services.mozilla.com/D42496
--HG--
extra : moz-landing-system : lando
This allows its use in std algorithms and types that require a real iterator
(like `template <typename InputIt> std::string::string(InputIt, InputIt)`).
Differential Revision: https://phabricator.services.mozilla.com/D42452
--HG--
extra : moz-landing-system : lando
`Reader::At()` can be used to get a `BlockIterator` at a given `BlockIndex`,
clamped between `begin()` and `end()`.
This will be useful when we want to iterate starting at a given index, e.g.,
when duplicating stacks.
Differential Revision: https://phabricator.services.mozilla.com/D42449
--HG--
extra : moz-landing-system : lando
(Also MOZ_BASE_PROFILER_STARTUP.)
This makes it easier to keep that variable setup in the environment, and change
its value to switch between enabling and disabling the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D42447
--HG--
extra : moz-landing-system : lando
In practice the Reader doesn't need to be copied/moved/reassign.
BlocksRingBuffer::Read() can just instantiate one on the stack, and pass it by
reference to callbacks.
Differential Revision: https://phabricator.services.mozilla.com/D42118
--HG--
extra : moz-landing-system : lando
The point of the EntryReserver was mainly to have an object that represented a
writing lock on BlocksRingBuffer, so potentially perform multiple consecutive
writes.
After some experience implementing bug 1562604, there's actually no need for it.
So instead of having `Put()` create an `EntryReserver`, we now have
`ReserveAndPut()` that does the whole work in one function.
Differential Revision: https://phabricator.services.mozilla.com/D42116
--HG--
extra : moz-landing-system : lando
EntryWriter doesn't even need to be moveable, as BlocksRingBuffer can just
create one on the stack, and pass it by reference to callbacks.
This removes risks, and potential data copies.
Differential Revision: https://phabricator.services.mozilla.com/D42115
--HG--
extra : moz-landing-system : lando
Actually, we use clang for all Linux and Android platform, so it is no reason to use frame pointer based stack walker for LUL on Android/x86 and Android/x86-64 if no DWARF rule.
Differential Revision: https://phabricator.services.mozilla.com/D41320
--HG--
extra : moz-landing-system : lando
`BlocksRingBuffer` will be used both inside and outside `ProfileBuffer`:
- Inside to serve as `ProfileBuffer`'s main storage for stack traces,
- Outside to allow marker storage even when `ProfileBuffer` is locked during
stack sampling.
`ProfileBuffer` only exists while `ActivePS` is alive, but because of the
potential outside accesses above (due to small races between ProfileBuffer
shutdown, and thread-local IsBeingProfiled() flags), we cannot just do the same
for BlocksRingBuffer, and it must remain alive to gracefully deny these accesses
around the profiler startup and shutdown times.
To accomplish this, `BlocksRingBuffer` may be in different states:
- "In-session", we have a real buffer to write to and read from,
- "Out-of-session", without buffer so reads&writes do nothing.
This is implemented by enclosing the underlying `ModuloBuffer` and the entry
deleter in a `Maybe`, which may be `Nothing` when the profiler is not running
and the `ProfileBuffer`'s `BlocksRingBuffer` is out-of-session.
Differential Revision: https://phabricator.services.mozilla.com/D41519
--HG--
extra : moz-landing-system : lando
`BlocksRingBuffer` will be used both inside and outside `ProfileBuffer`:
- Inside to serve as `ProfileBuffer`'s main storage for stack traces,
- Outside to allow marker storage even when `ProfileBuffer` is locked during
stack sampling.
`ProfileBuffer` only exists while `ActivePS` is alive, but because of the
potential outside accesses above (due to small races between ProfileBuffer
shutdown, and thread-local IsBeingProfiled() flags), we cannot just do the same
for BlocksRingBuffer, and it must remain alive to gracefully deny these accesses
around the profiler startup and shutdown times.
To accomplish this, `BlocksRingBuffer` may be in different states:
- "In-session", we have a real buffer to write to and read from,
- "Out-of-session", without buffer so reads&writes do nothing.
This is implemented by enclosing the underlying `ModuloBuffer` and the entry
deleter in a `Maybe`, which may be `Nothing` when the profiler is not running
and the `ProfileBuffer`'s `BlocksRingBuffer` is out-of-session.
Differential Revision: https://phabricator.services.mozilla.com/D41519
--HG--
extra : moz-landing-system : lando
After some bad experiences, I think EntryReader should be move-only:
- It needs to be moveable so it can be created from a function, and move-
constructed into a Maybe<> if needed.
- It can be passed around as a reference.
Previously, it could be passed by value, but it was too easy to create bugs,
e.g.: A function delegates to a sub-function to read something at the beginning,
then the first function wants to read more past that, but if the reader was
passed by value the first function would not see past what the sub-function did
read.
As a bonus, `mRing` can now be a reference instead of a pointer, and other
members can be const.
Differential Revision: https://phabricator.services.mozilla.com/D40958
--HG--
extra : moz-landing-system : lando
It makes little sense to copy a writer (also an output iterator).
We're keeping it move-constructible (so it can be passed around for construction
purposes), but not move-assignable to help make more members `const`.
Differential Revision: https://phabricator.services.mozilla.com/D40622
--HG--
extra : moz-landing-system : lando
This makes it easier to grab all BlocksRingBuffer state variables:
- Range start and end.
- Number of pushed blocks/entries, number of cleared blocks/entries.
The function is thread-safe, and the returned values are consistent with each
other, but they may become stale straight after the function returns (and the
lock is released).
They are still valuable to statistics, and to know how far the range has at
least reached (but may go further soon).
Differential Revision: https://phabricator.services.mozilla.com/D40621
--HG--
extra : moz-landing-system : lando
Renamed `BPAutoLock` to `BaseProfilerAutoLock`.
DEBUG-build `~BaseProfilerMutex()` checks that it is unlocked.
Prevent `BaseProfilerMutex` and `BaseProfilerAutoLock` copies&moves.
DEBUG-build check that `Lock()` sees `mOwningThreadId`==0 (because that is the
initial value, and the value after a previous `Unlock()`).
Don't preserve atomic `mOwningThreadId` in JS recording.
Differential Revision: https://phabricator.services.mozilla.com/D40620
--HG--
extra : moz-landing-system : lando
`ProfilerMarkerPayload::Set...()` functions are only used by derived classes in
the same files, and these values could just be set during construction.
Differential Revision: https://phabricator.services.mozilla.com/D40619
--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
This of course checks that the mutex is locked as expected in non-public APIs.
It also checks that user callbacks will not keep readers/writers longer than
they should.
Differential Revision: https://phabricator.services.mozilla.com/D39625
--HG--
extra : moz-landing-system : lando
`BaeProfilerMutex` is a concrete mutex based on MutexImpl, which was previously
implemented twice in both platform.h and BlocksRingBuffer.h.
This combined mutex has some DEBUG code (when MOZ_BASE_PROFILER is #defined) to
catch recursive locking, and to assert that the mutex is held (for code that
cannot easily use the "proof of lock" pattern; e.g., going through user-provided
callbacks).
This class needs to be public (because it is used in public headers), but is an
implementation detail, so it is located in a new header
"mozilla/BaseProfilerDetail.h" that will collect `mozilla::baseprofiler::detail`
code that may be useful to a few files in Base Profiler.
Differential Revision: https://phabricator.services.mozilla.com/D39624
--HG--
extra : moz-landing-system : lando
`ClearBefore()` with a past-the-end `BlockIndex` was calling `Clear()`, which
tried to take the lock again! Also we didn't return after that.
Fixed, and added corresponding test.
Also: Removed ambiguous "delete" word, now using more precise "destroy" or
"entry destructor".
Differential Revision: https://phabricator.services.mozilla.com/D38846
--HG--
extra : moz-landing-system : lando
This is a similar concept as `nullptr` is to a pointer.
`BlocksRingBuffer` now skips the first byte in the buffer, so that no entries
start at 0 (the internal default `BlockIndex` value).
All `BlocksRingBuffer` public APIs handle this default value, and do nothing
and/or return Nothing (as if it pointed at an already-deleted entry).
Added tests for this, and for all BlockIndex operations.
Differential Revision: https://phabricator.services.mozilla.com/D38667
--HG--
extra : moz-landing-system : lando
Without declaring them, ModuloBuffer had its copy&move constructor&assignments
defaulted. This means it could have been copied, and then both objects would now
own the same resource and attempt to free it on destruction!
So now:
- Copy construction&assignment are now explicitly disallowed.
- Move assignment is disallowed, to keep some members `const`.
- Move construction is allowed (so a function can return a ModuloBuffer), and
ensures that the moved-from object won't free the resource anymore.
Bonus: `mBuffer` is now `const`, to ensure that it cannot point at something
else, but note the pointed-at bytes are *not* const.
So ModuloBuffer is like an unchanging resource, but it allows to be moved-from
as an xvalue that should not be used after the move.
Differential Revision: https://phabricator.services.mozilla.com/D38665
--HG--
extra : moz-landing-system : lando
By default `ModuloBuffer` allocates its own buffer on the heap.
Now `ModuloBuffer` adds two alternatives:
- Take ownership of a pre-allocated `UniquePtr<uint8_t>` buffer.
- Work over an unowned `uint8_t*` array. The caller is responsible for
ownership, and ensuring that the array lives at least as long as the
`ModuloBuffer`/`BlocksRingBuffer`.
`BlocksRingBuffer` can pass along these new options to its underlying
`ModuloBuffer`.
The main use will be for small on-stack `BlocksRingBuffer` that can store a
stack trace, or to more easily collect data (without allocating anything on the
heap) that can then go into the upcoming `ProfileBuffer`'s `BlocksRingBuffer`.
Differential Revision: https://phabricator.services.mozilla.com/D38285
--HG--
extra : moz-landing-system : lando
This adds to the byte-oriented ModuloBuffer from bug 1563425:
- Thread-safety: All APIs may be called at any time from any thread.
- Structure: The buffer will be divided in "blocks" of different size, with some
block meta-data and space for the user "entry".
- Capable of handling user resources: The user may provide a "deleter" that will
be informed about soon-to-be-destroyed entries; so if some entries reference
outside resources, these references may be properly released.
Note: This first implementation still only allows the user to manipulate bytes
and trivially-copyable objects (same as with the ModuloBuffer iterators). A
follow-up bug will introduce better serialization capabilities, with the aim to
eventually store everything that current Profiler Markers and their payloads
contain.
Differential Revision: https://phabricator.services.mozilla.com/D37702
--HG--
extra : moz-landing-system : lando
Basic usage:
- Create buffer: `ModuloBuffer mb(PowerOfTwo);`
- Get iterator: `auto writer = mb.WriterAt(Index);` (or `ReaderAt()`)
- Basic iterator functions on bytes: `*++writer = 'x';`
- Write: `writer.WriteULEB128(sizeof(int)); writer.WriteObject<int>(42);`
- Comparisons, move: `while (writer > reader) { --writer; }`
- Read: `size_t s = reader.ReadULEB128<size_t>(); int i = ReadObject<int>();`
There are no safety checks, it will be up to the caller to ensure thread-safety,
and data safety when wrapping around the buffer.
Differential Revision: https://phabricator.services.mozilla.com/D36869
--HG--
extra : moz-landing-system : lando
Bug 1556993 fixed the crash in PoisonIOInterposer (due to missing stdout&stderr
fd's), and bug 1559379 fixed the mozglue memory issue that the unit test
experienced.
So now Base Profiler can be enabled by default on Windows, still using
`MOZ_BASE_PROFILER_...` env-vars for now (upcoming bug will merge these with
non-BASE env-vars soon).
Differential Revision: https://phabricator.services.mozilla.com/D37355
--HG--
extra : moz-landing-system : lando
Now that Gecko Profiler only registers its entry&exit functions when running,
and it ensures that Base Profiler is stopped beforehand, Base Profiler can now
register its own entry&exit functions to capture labels before xpcom starts.
Differential Revision: https://phabricator.services.mozilla.com/D34810
--HG--
extra : moz-landing-system : lando
The new ProfileBuffer data structure will need to store block sizes (usually
small, LEB128 uses fewer bytes for small numbers), and the circular buffer will
provide iterators that hide the wrapping-around.
Differential Revision: https://phabricator.services.mozilla.com/D36473
--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
alwu
Gerald Squelart
Chris Fronk
Markus Stange
Greg V
Emilio Cobos Álvarez
Nazım Can Altınova
André Bargull
James Willcox
Razvan Maries
Bogdan Tara
Bob Owen
Narcis Beleuzu
shindli
Simon Giesecke
Mike Hommey
Cameron Kaiser
Andrew McCreight
Ciure Andrei
Arthur Iakab
Jeff Walden
Randell Jesup
Brindusan Cristian
Toshihito Kikuchi
Makoto Kato
Greg Tatum
Sylvestre Ledru
Julien Wajsberg