This patch changes the snapshotting code for keyed histograms
so that requesting a snapshot does not report expired histograms.
MozReview-Commit-ID: GDiw6yOcF8J
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This patch changes GeckoView persistence code so that it will always get compiled
and linked to the final executable, even outside of Android. By doing so, we are
able to easily add gtest coverage for this code on all platforms other than Android
on which gtest is not yet supported.
In addition to that, this patch adds proper test cases for measurements' serialization
and deserialization for both scalars and histograms.
MozReview-Commit-ID: J0Snhl3Y8jk
This is needed as we might end up serializing only one process, but its id might
be greater than 1 when deserializing.
MozReview-Commit-ID: EzXOOhlNV1Y
This ensures that histograms that are not allowed on a product will not
be present in a snapshot. This is mainly to work around the fact that
legacy flag histograms are always reported, even if they are not set.
MozReview-Commit-ID: EyR6KhjPC4o
This patch factors out the code needed to take snapshots for plain
histograms. These functions will be used for generating a snapshot
for the persistence logic as well.
MozReview-Commit-ID: 37kx3WidlhJ
This patch makes sure that snapshotting is performed while
holding the histogram mutex. JS reflection code is only called
after the snapshot is taken, outside of the locked section.
MozReview-Commit-ID: H1uJz1H7rIu
This patch introduces a couple of new functions to copy histogram data
to Mozilla-friendly arrays. This solves the problem of passing Histogram
pointers around and makes working away from JS functions easier.
MozReview-Commit-ID: BIg3FXBzxfT
On Desktop and GeckoView we only ever need to store histograms for a
subsession and clear the histograms when a snapshot is done (e.g. a main ping is built).
On Fennec we don't have subsessions and only store for a session and never clear the storage.
MozReview-Commit-ID: BeVi86kZPs2
On Desktop and GeckoView we only ever need to store histograms for a
subsession and clear the histograms when a snapshot is done (e.g. a main ping is built).
On Fennec we don't have subsessions and only store for a session and never clear the storage.
MozReview-Commit-ID: BeVi86kZPs2
The "products" property is optional and defaults to `firefox, fennec`.
Recording of histograms is disabled if the probe doesn't have the products
property for the current running product.
MozReview-Commit-ID: 3puMXbuicuC
Factored out common code between JSHistogram_Add and JSKeyedHistogram_Add
to get values from array, and handle case of single accumulation.
Uses type checking utility function introduced in bug 1428893.
The code for serializing an EventKey in SerializeEventsArray does
something peculiar: it creates a temporary array of nsCStrings, copies
the appropriate strings from the event info for the key, and then
converts those into JavaScript strings. But we shouldn't need to do any
copying into the temporary array. We can do everything directly on the
strings from the event info themselves.
It seemed best to introduce a ToJSString for this purpose, which comes
in handy in a couple other places as well.
This patch adds support for value arrays to the internal_JSHistogram_Add method.
The histogram.add() js method can now be called with a single value or an array of values.
The accumulation is "all-or-nothing", i.e. if there is even a single invalid value in the
array, then nothing is accumulated.
The logic for type checking arguments before accumulation has been moved into a separate
function: internal_JSHistogram_CoerceValue. This function can also be used for
internal_JSKeyedHistogram_* methods in the future. This patch includes logic for clamping
values greater than UINT32_MAX to UINT32_MAX.
Added xpcshell tests in telemetry/tests/unit/test_TelemetryHistograms.js to check functionality.
We need to clamp accumulations to fit in our data representation (int). This
patch records the number of times, and for which probes, we had to do so.
MozReview-Commit-ID: GSs3oFvLKlL
Internally Histograms use int, which is signed.
Our API uses uint32_t, which is not.
Our JS API uses ToUint32, which takes provided values modulo UINT32_MAX.
This patch consolidates behaviour so that all values greater than INT_MAX will
be correctly recorded in the highest bucket of a Histogram... instead of
having values between INT_MAX and UINT32_MAX end up as 0s, and values above
UINT32_MAX being taken modulo UINT32_MAX, but only from the JS API.
MozReview-Commit-ID: CzaaNZkPEji
Telemetry::Accumulate now supports two new signatures: Accumulate(HistogramId, nsTArray stringLabels) and
Accumulate(nsTArray enumValues). In the stringLabels case, if the array contains an invalid label, then no
samples are accumulated at all. In the enumValues array case, the class template ensures that we do not have
a mismatch of labels in the array, since the enumValues class is tied to the id of the histogram we want to
accumulate to.
This switches from `nsDependentCString` to `nsLiteralCString` when adding
histograms to the table. It will help save some memory and should avoid the OOM
smalls we have been seeing.
Extended the Telemetry::Accumulate API to take a Histogram ID, string key, and a nsTArray<uint32_t> of samples.
Test cases check for linear, count and histograms with a set of allowed keys. Made changes to fix try failures.
Added another Telemetry::Accumulate function that takes a histogram id and an array of samples as arguments.
As of this patch, adding multiple samples to keyed and categorical histograms is not supported.
Since LinearHistogram and its descendants inherit ranges_ from
Histogram, and we wanted to replace the copying into a std::vec
for Histogram, the simplest approach seemed to just be to
precompute ranges for all histograms, exponential or otherwise.
This should have the added benefit of reducing the memory
footprint for those histograms, since they will benefit from the
deduplication work that the precomputing script already does.
MozReview-Commit-ID: JTV5Dej5ZIb
Switch from static multi-dimensional arrays to dynamic one-dimensional arrays
that are only allocated in the parent process.
MozReview-Commit-ID: tyGEFhU2Fq
Switch from static multi-dimensional arrays to dynamic one-dimensional arrays
that are only allocated in the parent process.
MozReview-Commit-ID: tyGEFhU2Fq
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
The log and exp calls in base::Histogram::InitializeBucketRange()
were showing up in profiles. This patch uses the precomputed
buckets for exponential histograms instead of computing them at
runtime. Though linear histograms do show up in the profile that
prompted this change, they contribute much less, and due to the
trivial nature of generating these, it's unlikely that a static
cache would provide much if any speedup.
MozReview-Commit-ID: IavFwoWjFhk
The log and exp calls in base::Histogram::InitializeBucketRange()
were showing up in profiles. This patch uses the precomputed
buckets for exponential histograms instead of computing them at
runtime. Though linear histograms do show up in the profile that
prompted this change, they contribute much less, and due to the
trivial nature of generating these, it's unlikely that a static
cache would provide much if any speedup.
MozReview-Commit-ID: IavFwoWjFhk
Previously we assumed count histograms were always present in payloads.
This was an erroneous assumption as count histograms were only 0 if they were
session histograms, or if they were from subsession histograms from subsessions
_after_ a subsession when they held a non-0 value.
So let's just treat count histograms as normal histograms from now on, without
any of this "sometimes 0" nonsense. This simplifies the code, tests, and our
understanding... and _should_ have few/zero downstream effects since the
existing behaviour was so poorly-understood (though exactly tested).
MozReview-Commit-ID: BH108ksygGw
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
