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
This also fixes an existing bug where we checked for the wrong type in JSKeyedHistogram_Add().
KeyedHistogram::GetHistogramType() returns one of the histogram types from nsITelemetry.idl, not one of the chromium types (base::*).
I extended the test coverage accordingly, as it seemed to be lacking.
Dropped the dataset() functions from keyed and plain histograms in file |toolkit/components/telemetry/TelemetryHistogram.cpp| to prevent their unnecessary exposure while getting histograms using the getHistogramById function (or its keyed counterpart).
Also removed the (now redundant) |internal_JSHistogram_Dataset()| and |internal_JSKeyedHistogram_Dataset()| functions from the same file and tests from the file |toolkit/components/telemetry/tests/unit/test_TelemetryHistograms.js| as the same tests are performed later on in that very file.
Changed |print("enum ID : uint32_t {", file=output)| to |print("enum HistogramID : uint32_t {", file=output)| at line 53 of the file |toolkit/components/telemetry/gen-histogram-enum.py|, and then replaced all the textual occurrences of |Telemetry::ID| to |Telemetry::HistogramID| and |ID| to |HistogramID| in 43 other files.
NS_DispatchToMainThread can fail catastrophically during shutdown. Simply
listening for shutdown isn't enough to prevent catastrophe. So directly fetch
the main thread and, if you can't, then don't try to use it.
MozReview-Commit-ID: 7iFQEqqQekB
There is a mechanism to selectively turn hgram recording off and on. This is
presently only used to throttle an otherwise-devastatingly-chatty hgram to only
contain accumulations from specific times (sync scroll).
This was only checked on the parent. This checks it on the child as well.
MozReview-Commit-ID: 4f0VXMHLaPW
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
