Currently the Gecko Profiler defines a moderate amount of stuff when
MOZ_GECKO_PROFILER is undefined. It also #includes various headers, including
JS ones. This is making it difficult to separate Gecko's media stack for
inclusion in Servo.
This patch greatly simplifies how things are exposed. The starting point is:
- GeckoProfiler.h can be #included unconditionally;
- everything else from the profiler must be guarded by MOZ_GECKO_PROFILER.
In practice this introduces way too many #ifdefs, so the patch loosens it by
adding no-op macros for a number of the most common operations.
The net result is that #ifdefs and macros are used a bit more, but almost
nothing is exposed in non-MOZ_GECKO_PROFILER builds (including
ProfilerMarkerPayload.h and GeckoProfiler.h), and understanding what is exposed
is much simpler than before.
Note also that in BHR, ThreadStackHelper is now entirely absent in
non-MOZ_GECKO_PROFILER builds.
With the removal of the old addonHistograms, all histograms are now registered.
So removing registered(Keyed)Histograms should be straightforward?
Unfortunately not, as this was how we filtered data based on dataset
(opt-in/opt-out), so a little more fiddling was needed to get C++ to only
serialize dataset-appropriate data (instead of post-facto filtering it in JS).
MozReview-Commit-ID: HDplhmzmzJl
HangAnnotations was very complex, required a separate allocation, and used this
unfortunate virtual interface implementation which made it harder to do
interesting things with it (such as serialize it over IPC).
This new implementation is much simpler and more concrete, making
HangAnnotations simply be a nsTArray<Annotation>. This also simplifies some of
the IPC code which was added in part 7.
MozReview-Commit-ID: EzaaxdHpW1t
We're going to use HangDetails as the type containing hang information. We'll
have a JS component which reads the data out of nsIHangDetails, builds the
payload, and submits it to telemetry for us.
We'll do it in JS because telemetry has to be submitted from JS.
This patch also adds IPC serization for the relevant types so that we can send
HangDetails objects over IPDL.
MozReview-Commit-ID: CeikKabY9Vs
HangAnnotations was very complex, required a separate allocation, and used this
unfortunate virtual interface implementation which made it harder to do
interesting things with it (such as serialize it over IPC).
This new implementation is much simpler and more concrete, making
HangAnnotations simply be a nsTArray<Annotation>. This also simplifies some of
the IPC code which was added in part 7.
MozReview-Commit-ID: EzaaxdHpW1t
We're going to use HangDetails as the type containing hang information. We'll
have a JS component which reads the data out of nsIHangDetails, builds the
payload, and submits it to telemetry for us.
We'll do it in JS because telemetry has to be submitted from JS.
This patch also adds IPC serization for the relevant types so that we can send
HangDetails objects over IPDL.
MozReview-Commit-ID: CeikKabY9Vs
To cut down on complexity, we don't require specifying any expiry versions.
Given that these events will be recorded non-persistently from off-train add-ons, they can be expired by shipping new add-on releases.
We also start to use the new "record on release" terminology here instead of opt-in/opt-out, but are not changing the internal functionality yet.
Technically, this is implemented by keeping a separate registry for the dynamic event information.
Built-in & dynamic events are tracked with separate numeric ids, so introduce a common identifier for both, an EventKey.
For actual event storage, the events are treated the same as built-in events. They are simply bucketed into the 'dynamic' process storage.
This approach ends up duplicating code paths that use the event info, but keeps a single implementation for recording, storage & serialization.
TelemetrySession's getKeyedHistograms asks for each keyed histogram
individually. This is inefficient and doesn't work well with the storage
refactor.
So, plumb through a subsession keyed histogram snapshot API and convert
TelemetrySession over to using it.
MozReview-Commit-ID: Af9dTqw99UA
The Chromium IPC histogram code used the StatisticsRecorder object for storage.
This is keyed by histogram name, which doesn't match our storage reality anymore.
Instead we use a name to refer to a set of histogram instances that record data from different processes, as well as separating session and subsession data.
Consequently we need to rewrite this storage, which means StatisticsRecorder is not used anymore.
MozReview-Commit-ID: 1LC7YubpKaD
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.
When upgrading an old profile that still uses "downloads.sqlite", information about in-progress and paused downloads will be lost. The history of completed downloads will be preserved because it is stored in the Places database, although it may be affected by history expiration.
MozReview-Commit-ID: GFqvACKC4E1
When sending the shutdown ping we launched the pingsender executable via
PR_CreateProcessDetached() which on both Linux and MacOS X would fork()
gecko's main process and then exec() the pingsender executable. On MacOS X
this seemed to trigger a race with the mozalloc shutdown procedure within the
forked process. This patch changes the telemetry logic to use nsIProcess
instead which relies on posix_spawnp() to launch the new executable making it
immune to issues related to mozalloc's shutdown.
Since we don't need C++ code anymore to run the pingsender the runPingSender()
method is also moved to TelemtrySend.
MozReview-Commit-ID: C7fZw1ZpVBO
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
addonHistograms isn't being used and has started getting in the way.
So it goes.
Leave the "Addon Histograms" section in about:telemetry for 60 days.
Remove it in bug 1355882
MozReview-Commit-ID: 4lm7ONirofl
Currently we hand over a crash ping to the pingsender via a pipe; if the
pingsender fails to send the ping we rely on the CrashManager assembling and
sending one instead. Since the crashmanager is not aware of whether the ping
was sent or not this causes duplication on the server side. To solve this
problem we save the ping to disk instead, read it from the pingsender and
delete the file only if the ping was sent. In this scenario the CrashManager
will know that a ping was already sent and will not send a new one.
This patch removes all the code used to deal with pipes between the telemetry,
crashreporter and pingsender code and also tries to cut down the amount of
platform-specific code we have in this machinery.
MozReview-Commit-ID: ASm2jnDagCK
