Lock calls to internal_Accumulate from functions that run without locks.
This doesn't render TelemetryHistogram perfectly threadsafe. However,
this does protect all accumulation sites.
MozReview-Commit-ID: 16JUek8NiXI
We've now seen an OOM trying to grow the accumulations array during a test
suite. The g*Accumulations arrays do grow unboundedly in size waiting for the
IPC timer to fire, so we should put a size bound as well as a time bound to
trigger the batch send.
The current size bound is 5K elements. This was chosen out of a hat.
MozReview-Commit-ID: 5HeWdbLfN03
We're seeing occasional failures of the isValid assert on the parent side where
the ID we're being asked to accumulate on is invalid.
Check the IDs on both sides to ensure that they're valid heading in.
MozReview-Commit-ID: 4gLG54Tx64s
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
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
