nsTimer fires on the thread that created the timer. An nsTimer instance should
only be manipulated on its target thread (it isn't threadsafe). IPC using
PContent must be on the main thread.
Thus, everything to do with the gIPCTimer must be on the main thread.
This also takes care of bug 1299312.
MozReview-Commit-ID: IcVRYsoX2R9
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
Carsten "Tomcat" Book
Ryan VanderMeulen
Benjamin Bouvier
Dragana Damjanovic dd.mozilla@gmail.com
Francois Marier
AdamG2
Thom Chiovoloni
Mason Chang
kaku@mozilla.com
Wes Kocher
Christoph Kerschbaumer
Georg Fritzsche
Mike Conley
Timothy Nikkel
Andrea Marchesini
Phil Ringnalda
Tom Schuster
Chris H-C
Johann Hofmann
Bob Owen
Mark Banner