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
Currently the choices of SingleLineStyle and MultiLineStyle are sub-optimal,
which makes debugging of profiles difficult.
- A large chunk of the profile is put on a single line, which is very hard to
read in a text editor.
- Other short and repetitive constructs are unnecessarily spread across
multiple lines.
This patch makes things more readable.
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
When set to true, the resulting profile will have a non-null meta.shutdownTime
field which is set to current time.
Non-shutdown profiles also get that field, but it's null for them.
MozReview-Commit-ID: 1vpmhBR8rC6
--HG--
extra : rebase_source : b026088053c30acd287f0dc3afa7ddf14093ec27
This avoids large gaps in the profiler output.
Sometimes we hold on to exit profiles for a long time before a profile is
gathered. During that time, the parent process's profile buffer might have
looped around several times. At that point, profiles from processes that have
exited long ago are no longer interesting.
MozReview-Commit-ID: 5C47vb69DfK
--HG--
extra : rebase_source : 57f0df2f21ab778ec689a08d0bbf010b10f18ed9
This handles the case where the profiler state changes in the parent process
between the initial launch of the child process and the time at which the
PProfiler connection is established.
MozReview-Commit-ID: 5SQme5M7P30
--HG--
extra : rebase_source : 301d5541ff5c05a9540e45f1b57c13fb37d5d6fa
This also fixes the bug where we would always profile child processes if the
parent process had been launched with MOZ_PROFILER_STARTUP=1, regardless of
whether the profiler was still running in the parent process.
MozReview-Commit-ID: LkIpYmKJOJ1
--HG--
extra : rebase_source : 49b38bc58ded91ecc2e2fce08bcb4f2d20a13b92
PROFILER_MARKER is now just a trivial wrapper for profiler_add_marker(). This
patch removes it.
--HG--
extra : rebase_source : 9858f34763bb343757896a91ab7ad8bd8e56b076
This patch reduces the differences between builds where the profiler is enabled
and those where the profiler is disabled. It does this by removing numerous
MOZ_GECKO_PROFILER checks.
These changes have the following consequences.
- Various functions and classes are now defined in all builds, and so can be
used unconditionally: profiler_add_marker(), profiler_set_js_context(),
profiler_clear_js_context(), profiler_get_pseudo_stack(), AutoProfilerLabel.
(They are effectively no-ops in non-profiler builds, of course.)
- The no-op versions of PROFILER_* are now gone. The remaining versions are
almost no-ops when the profiler isn't built.
--HG--
extra : rebase_source : 8fb5e8757600210c2f77865694d25162f0b7698a
Once the |aPayload| argument to profile_add_marker() became a UniquePtr the
default value of nullptr caused compilation difficulties that could only be
fixed by #including ProfilerMarkerPayload.h into lots of additional places
(because the UniquePtr<T> instantiation required the T to be fully defined). To
get around this I just split profile_add_marker() into two functions, one with
1 argument and one with 2 arguments.
The patch also removes the definition of PROFILER_MARKER_PAYLOAD in the case
where MOZ_GECKO_PROFILER isn't defined. A comment explains why.
