Received exit profiles are now stored in the main process' ActivePS and managed
there, including discarding expired profiles (when they don't intersect with the
parent's profile anymore).
nsProfiler may grab exit profiles from the profiler when the add-on needs them.
On shutdown, the profiler now includes non-expired exit profiles.
Differential Revision: https://phabricator.services.mozilla.com/D20277
--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
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
MozPromise most common use is to have an single or exclusive listener. By making the MozPromise generated by IPDL exclusive we can also use move semantics.
While at it, we also use move semantics for the ResponseRejectReason and via the callback's reject method so that the lambda used with the MozPromise::Then can be identical to the one used by the IPDL callback.
As it currently is, it provides no advantage over a copy as it's just an enum; however, this will facilitate future changes where it may not be.
Differential Revision: https://phabricator.services.mozilla.com/D13906
--HG--
extra : moz-landing-system : lando
At this point, we've freshly allocated data for the generated JSON.
There's no need to copy it into a separate nsCString; we can simply
adopt the generated JSON into the nsCString, saving a copy.
(Unless there were other profiler actions, as I'm not sure yet whether it would
be safe to skip them when the profiler is paused; another bug should
investigate that.)
Differential Revision: https://phabricator.services.mozilla.com/D11308
--HG--
extra : moz-landing-system : lando
JSONWriter currently calls new and delete indirectly through mozilla::MakeUnique to allocate a buffer. Becuase of this, the methods of this class cannot be invoked within Spidermonkey due to https://searchfox.org/mozilla-central/source/config/check_vanilla_allocations.py#6-14. Therefore, JSONWriter needs an AllocPolicy template parameter so that the allocation and deallocation routines can be changed to match the JS AllocPolicy when invoked within SpiderMonkey.
Differential Revision: https://phabricator.services.mozilla.com/D7279
--HG--
extra : moz-landing-system : lando
r?njn for the profiler parts
r?jrmuizel for the ELF parsing parts
Depends on D7020
Differential Revision: https://phabricator.services.mozilla.com/D7021
--HG--
extra : moz-landing-system : lando
r?njn for the profiler parts
r?jrmuizel for the ELF parsing parts
Depends on D7020
Differential Revision: https://phabricator.services.mozilla.com/D7021
--HG--
extra : moz-landing-system : lando
We were using nsCString to pass the profiler data between processes. But it was
failing to send because there is a ~256MB limit for the string data. So we
changed it to use Shmem instead. Shmem creates a shared memory and passes the
weak reference. With it, we can send larger data without having a problem.
MozReview-Commit-ID: 1kj57fZDXVF
--HG--
extra : rebase_source : 25a8ab57bcae8012fee1cdd9d4b767036db192d7
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
To add test for startProfiler's parameters on devtools, nsIProfilerStartParams
changes to scriptable.
MozReview-Commit-ID: 3Rf39NzsND1
--HG--
extra : rebase_source : 2b4fc908e7c611a36ac8766b9ce7ccd55f2c5620
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
They are equivalent -- both infallible, both requiring measuring the length of
the string -- but moz_xstrdup is much more readable. (One place deals with
16-bit strings and so uses NS_strdup instead, which is also infallible.)
The patch also removes some failure-path code that will never execute due to
the infallibility.
--HG--
extra : rebase_source : 115574cf55db90b60e6bee59e5dc6ee409374159
