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
