When it's false we also disable collecting events completely, in case the
reason we're disabling it is due to storage issues.
GeckoView doesn't presently support Events, so the 'event' ping is disabled by
default for that platform.
MozReview-Commit-ID: 9eKAtRiuER0
Instead of a hard cap, introduce a topic to notify when we reach the now-
preference-controlled per-process event record limit. Also add the capability
to leave some records behind in storage for the next call.
MozReview-Commit-ID: EY40tqKxxeW
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 means that during a normal "mach build faster" build all the events
will be overwritten, as the generated EventArtifactsDefinitions.json
contains all events from the Events.yaml it was generated from.
Real dynamic events follow similar code paths internally.
We also ensure they trigger the right code path and don't overwrite.
MozReview-Commit-ID: JvFZfwCbjQN
Using a separate storage just for dynamic-builtin events was adopted
from the Scalar implementation of dynamic builtins, where the second
storage was needed because of the way IDs are constructed.
Events however use "category#method#object" for the key, making separate storage unnecessary.
Having that additional storage leads to problems along the way.
One of them is the snapshotter failing to properly accumulate from both storages
into a single array.
In addition, even if those are merged, an additional sort step would be
necessary to keep events ordered by time of occurence. And even then it
can't guarantee exact order for events from different storages but same
millisecond-time.
MozReview-Commit-ID: AefVyDRDqQB
Using a separate storage just for dynamic-builtin events was adopted
from the Scalar implementation of dynamic builtins, where the second
storage was needed because of the way IDs are constructed.
Events however use "category#method#object" for the key, making separate storage unnecessary.
Having that additional storage leads to problems along the way.
One of them is the snapshotter failing to properly accumulate from both storages
into a single array.
In addition, even if those are merged, an additional sort step would be
necessary to keep events ordered by time of occurence. And even then it
can't guarantee exact order for events from different storages but same
millisecond-time.
MozReview-Commit-ID: AefVyDRDqQB
This makes sure dynamic builtin events follow the same semantics as static builtin events.
On registration of the event the category is stored, but not enabled.
For fully-dynamic events, e.g. those registered by addons, the category
is enabled immediately (and can't be disabled).
This removes now-unused type definitions and switches from a map to a
simple set to store the category names.
The value stored in the map previously was not used at all.
In theory the map was effectively immutable after initialization, but
the check was only forced in debug anyway.
Now the set is mutable, but is only mutated in exactly 2 places.
MozReview-Commit-ID: 8tLEVXzHuHw
The "products" property is optional and defaults to `firefox, fennec`.
Recording of events is disabled if the probe doesn't have the products
property for the current running product.
MozReview-Commit-ID: EqTHq9duNT
Telemetry Events will now be counted in the keyed scalar
"telemetry.event_counts" even if their category is not enabled for recording.
The keys will be category#method#object and a follow-up commit will expand the
process limit of the number of these from 100 to 500, configurable by pref.
Unfortunately Event Telemetry needs a special API so that an event recorded in
multiple processes will be summarized to those processes separately.
MozReview-Commit-ID: 7dKcM3SXO6r
(This is a partial revert of bug 1443587 part 2 where the `Move`s were added.)
When registering multiple methods and objects within the same `eventData` item,
we must copy the list of acceptable event keys into each new DynamicEventInfo.
Also includes a test.
MozReview-Commit-ID: 5PSH15nSWEB
DNSRequestChild's constructor takes `const nsCString&` parameters. If
you have a `const nsACString&` argument to pass in to the constructor,
you're forced to construct a temporary nsCString object to satisfy the
prototype. But the temporary string will just get copied inside the
constructor and you'll have to destroy the temporary string object you
created.
Let's skip all this, and just have DNSRequestChild take `const
nsACString&` arguments instead, and avoid the temporary object.
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.
Once we've created the array of events for a given process, there's no
need to copy it in the array for all process events. We can Move() it
instead, which is more efficient.
When constructing DynamicEventInfo, we can require the extra keys to be
passed in by rvalue reference, rather than copying the entire array.
When registering dynamic events, we also don't need to construct an
entirely new nsCString to pass to the constructor; we can simply pass
the nsACString reference we received and go from there.
These methods are returning nsCString wrappers for static char arrays;
we only need to return nsDependentCStrings, rather than allocating and
copying entirely new nsCString objects.
To cut down on complexity, we don't require specifying any expiry versions.
Given that these events will be recorded non-persistently from off-train add-ons, they can be expired by shipping new add-on releases.
We also start to use the new "record on release" terminology here instead of opt-in/opt-out, but are not changing the internal functionality yet.
Technically, this is implemented by keeping a separate registry for the dynamic event information.
Built-in & dynamic events are tracked with separate numeric ids, so introduce a common identifier for both, an EventKey.
For actual event storage, the events are treated the same as built-in events. They are simply bucketed into the 'dynamic' process storage.
This approach ends up duplicating code paths that use the event info, but keeps a single implementation for recording, storage & serialization.
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
Updates the core Telemetry code to use the new headers and support the extension process.
TelemetryHistogram is not cleanly refactored here; doing this uncovered a few time consuming issues with the various lookup code paths.
TimeStamp::ProcessCreations()'s aIsInconsistent outparam is ignored by the
majority of its caller. This patch makes it optional. Notably, this makes
ProcessCreation() easier to use in a constructor's initializer list.
