Previously, the absence of "stackwalk", "leaf", and "javascript" implied that
the test/user didn't want any sampling, but this caused issues in some tests
that enabled "stackwalk" on platforms that didn't support stack-walking, which
ended up suppressing label-only stacks that the test expected.
we now have an explicit feature "nostacksampling" that disables backtraces from
the samplers in both profilers. This effectively cancels "stackwalk", "leaf",
and "javascript" if present.
Differential Revision: https://phabricator.services.mozilla.com/D47731
--HG--
extra : moz-landing-system : lando
I opted to go with what I perceived as the more expedient route
of leaving lz4 roughly where it is and just adding to that. The
biggest complication was xxhash, which is included elsewhere.
I'm not generally proficient with build-related things though so
my solution may be wrong and not just ugly.
Differential Revision: https://phabricator.services.mozilla.com/D30640
--HG--
rename : mfbt/lz4.c => mfbt/lz4/lz4.c
rename : mfbt/lz4.h => mfbt/lz4/lz4.h
extra : moz-landing-system : lando
An error crept in, resulting in:
```
[task ...] InterpreterError: InterpreterError: infix: [..] expects integer [..] integer
```
At some point, `suite` became a string name and not an object with a
string `name` member. However, in the interim, the diversity of
`command` structures has made the template approach untenable.
Therefore, this commit converts `GeckoProfile` to a `TryConfig`. The
existing test clearly wasn't helpful, and it doesn't really map to a
`TryConfig` test, so it was removed.
Differential Revision: https://phabricator.services.mozilla.com/D41603
--HG--
extra : moz-landing-system : lando
A bunch of loop-detection, etc, complexity goes away because mixins are not
interfaces and the mixin syntax does not allow various things we had to guard
against in terms of maplikes and whatnot.
Differential Revision: https://phabricator.services.mozilla.com/D46524
--HG--
extra : moz-landing-system : lando
Adds prefs to `IGNORE_PREFS` so that they will be overlooked by lintpref. `devtools.console.stdout.chrome`, `devtools.console.stdout.content`, and `browser.dom.window.dump.enabled` make use of the `sticky` attribute, and `fission.autostart` makes use of the `locked` attribute within all.js.
Differential Revision: https://phabricator.services.mozilla.com/D44887
--HG--
extra : moz-landing-system : lando
Linter that checks for duplicates between StaticPrefList.yaml and all.js. Also a starting point for other prefs linting tasks.
Differential Revision: https://phabricator.services.mozilla.com/D42340
--HG--
extra : moz-landing-system : lando
`BlocksRingBuffer` had an "entry destructor" to make it a more generic
container, and it was useful during early prototyping of the new profiler
storage (so that we could store owning pointers).
But this entry destructor is stored in an `std::function`, which gets marked as
a potential GC caller by the js rooting hazard analyzer; and as this bug found,
it's not obvious where to place `JS::AutoSuppressGCAnalysis`, because profiler
entries (including stacks) could be added on one thread while GC happens
elsewhere, which triggers the embedded `AutoAssertNoGC` check.
Since we don't actually use the entry destructor facility in the profiler, it's
easier to just get rid of it. As a bonus, it's a small optimization.
Tests that were using an entry destructor now use the `State` instead, to verify
that entries are pushed and cleared as expected.
If needed in the future outside of the profiler, `BlocksRingBuffer` could again
include an entry destructor, but it would have to be through templating, so that
the class used in the profiler wouldn't contain an `std::function`.
Differential Revision: https://phabricator.services.mozilla.com/D46738
--HG--
extra : moz-landing-system : lando
Split the GetCodeCoverageSummary API into a variant for a specific realm
vs checking all realms. This restores the original behaviour of the
getLcovInfo testing function to only return info on current realm. This
makes testing OOM behaviour much more predictable.
Differential Revision: https://phabricator.services.mozilla.com/D46167
--HG--
extra : moz-landing-system : lando
The code changes to use a profiler feature for the native allocations were deferred
until this commit.
Differential Revision: https://phabricator.services.mozilla.com/D42196
--HG--
extra : moz-landing-system : lando
The profiler backtraces inside a memory hook are re-entrant for the
profile lock. This patch adds additional guards to protect against this
in order to allow for a profiler backtrace during native allocations.
Differential Revision: https://phabricator.services.mozilla.com/D42195
--HG--
extra : moz-landing-system : lando
There is a bad interaction between the bloat log and the native allocation
tracking. There is a detailed message explaining the problem in the code.
Differential Revision: https://phabricator.services.mozilla.com/D42194
--HG--
extra : moz-landing-system : lando
This commit adds both the native allocation marker, and the Bernoulli
trial to attempt to sample the native allocations.
Differential Revision: https://phabricator.services.mozilla.com/D42193
--HG--
extra : moz-landing-system : lando
This commit adds a ThreadIntercept mechanism to block re-entry when
attempting to collect the stacks of native allocations.
A following commit will actually hook them up to collect allocations.
Differential Revision: https://phabricator.services.mozilla.com/D39882
--HG--
extra : moz-landing-system : lando
The ProfilerCounters had a static lifetime controlled by a UniquePtr. This
is an issue if the profiler mutex, which is also static, gets destroyed
first. The counters will then try to access the profiler mutex, and find
it already destroyed, leading to a crash. This commit changes the life
cycle to explicitly leak the counters for the lifteime of the process.
In addition, this patch adds explicit install and removal functions for
the memory hooks.
Differential Revision: https://phabricator.services.mozilla.com/D42192
--HG--
extra : moz-landing-system : lando
If all sampling-related features ("Native Stacks", "JavaScript", and "Native
Leaf Stack") are OFF, the sampler loop will not record any stack samples, not
even from labels, which should reduce the profiler overhead significantly.
This means that the sampling rate could be slowed down (up to 5s interval), to
help reduce the power consumption incurred by wake-ups for sampling.
Markers are not affected by this, and will all be recorded as expected.
However counters (e.g., memory allocations) are still tied to sampling, so their
sampling resolution will be reduced to whatever sampling rate is chosen.
Some existing tests relied on stack sampling happening, so they now enable at
least "leaf". Bug 1579333 may revisit these tests for a better solution (if
possible).
Differential Revision: https://phabricator.services.mozilla.com/D46753
--HG--
extra : moz-landing-system : lando
Profiling the profiler showed a lot of time spent allocating memory for the
frame-address strings, almost half the time of `StreamSamplesToJSON`!
Using an "Auto" string will prevent these allocations in most cases.
Also removed the `printf("0x%llx")`, instead just appending "0x" and an hex-
formatted number with `AppendInt()` (which handles 32- and 64-bit numbers
separately, so there is no more needs to do a double-cast to avoid sign
extensions -- There is still a double cast, but a no-op one to fix the type to
either `uint32_t` or `uint64_t`).
Using an Auto string for nearby frame labels as well.
Differential Revision: https://phabricator.services.mozilla.com/D45841
--HG--
extra : moz-landing-system : lando
Stack samples may contain up to hundreds or thousands of entries, which need to
be copied (during sampling and duplicating), and also mostly skipped when
creating the JSON output for other threads or other types of profile data.
This patch gathers all sample legacy entries (apart from the thread id and the
timestamp) into a single non-legacy entry, which is much faster to copy or
skip. The preceding timestamp now has a distinct Kind (`TimeBeforeCompactStack`)
to know whether to handle legacy entries of the new `CompactStack` entry kind.
Differential Revision: https://phabricator.services.mozilla.com/D45840
--HG--
extra : moz-landing-system : lando
profiler_can_accept_markers() is a fast and racy check that markers would
currently be stored, it should be used around potentially-expensive calls to
add markers.
And now markers are no longer stored when the profiler is paused. (Note that the
profiler is paused when a profile is being stored, this will help make this
operation faster.)
Differential Revision: https://phabricator.services.mozilla.com/D44434
--HG--
extra : moz-landing-system : lando
Since all profiler data is now stored inside ProfileBuffer, there is no real
need to continuously discard old data during sampling (this was particularly
useful to reclaim memory taken by old markers&payloads).
Instead, we can now just discard the old data once, just before starting to
stream it to JSON.
Differential Revision: https://phabricator.services.mozilla.com/D44433
--HG--
extra : moz-landing-system : lando
Now that what was in ProfilerMarker is stored directly in `BlocksRingBuffer`,
there is no need for this class anymore!
This also removes all the pointer management around it (when added to a TLS
list, moved during sampling, deleted when expired).
Differential Revision: https://phabricator.services.mozilla.com/D43431
--HG--
extra : moz-landing-system : lando
