Rewrite the categorical histogram accumulation code to use the common path.
This way it gets remote accumulation for cheap.
MozReview-Commit-ID: 3q6gdSvBix
I saw a one-off crash on try in internal_GetHistogramByEnumId. Not reproducible
but maybe possible if we're trying to accumulate using an invalid ID. So let's
guard against that.
MozReview-Commit-ID: Ei6eTlV91mJ
On content process shutdown we send a content process ping to ensure we have
up-to-date data from the content process before it goes away. Now we need to
also flush the batched telemetry accumulations to the parent so that it can be
present in the ping.
No attempt is made to synchronize access to IPCTimerFired. It is safe to
re-enter.
No attempt is made to cancel the timer as its firing is benign.
MozReview-Commit-ID: 1gjNH9IPhKf
Clear isn't generally called at all, and isn't dispatched to the parent process
for child telemetry aggregation. Clear should only be called on the parent
process.
MozReview-Commit-ID: stIutvAO6h
The JS histograms, too, need to dispatch their accumulations from child to
parent.
JSHistograms_Add now only supports histograms that are in gHistogramsMap or
that were created in the parent process. After bug 1288745, maybe we'll be able
to change this to be less convoluted.
MozReview-Commit-ID: 3qTH89YKbGP
Take the opportunity presented through changing child telemetry accumulation
to bring the ping form closer to the ideas expressed in bug 1281795.
childPayloads still exists, but without histograms or keyedHistograms which are
now at root.processes.content.{keyedH|h}istograms. This will require coordinated
changes in the aggregator and moztelemetry libraries.
MozReview-Commit-ID: AqG2jmBBC2W
To simplify using child telemetry from the parent process, only allow child
telemetry payloads to be generated once per child process, on shut down.
This will allow us to use the child telemetry's subsession information to leave
childPayloads the way it currently is.
Will need to update test_ChildHistograms.js as it is the only consumer.
MozReview-Commit-ID: 2qSztg0QHV5
I originally thought we'd be able to avoid the previous implementation's waste
of a map full of every kind of keyed histogram. Unfortunately, other code
(TelemetrySession at the very least) depends on this (and will throw if a keyed
histogram isn't present, even if it is empty)
MozReview-Commit-ID: 8MCGVa595UB
The original commit didn't properly support subsession histograms, so rectify
that lapse by adding support for stripping out the base name of a histogram
when trying to determine its id.
MozReview-Commit-ID: LvUek6f5WUx
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
The createEvent() method supports only a fixed list of legacy event
types, and we would like to converge with other browsers on a list of
events to support. To this end, we want to know if any supported types
are unused so we can drop them.
MozReview-Commit-ID: 8uB1vepBCpi
Telemetry peer review through mozreview.
This patch is modifying this probe description sligthly, to add the collection
of a special value: '0' means that only one keyframe was found when playing a
video (played for at least enough time to be eligible for video-decode-suspend
feature.)
Please note that this will not modify existing data or their meaning: It will
just add this zero value (which is not otherwise possible or meaningful when
dealing with *inter-keyframe* timings), which will help gauge the relative
presence of these difficult-to-recover-from videos, compared to more "normal"
videos.
MozReview-Commit-ID: ANFtybW9BKu
