The buffer range starts at 1 (the first valid entry, 0 is reserved as
null marker). So if it now starts *after* 1, it means we have started to
overwrite our oldest data, and we should get rid of Base profiles if any.
Differential Revision: https://phabricator.services.mozilla.com/D51225
--HG--
extra : moz-landing-system : lando
profile.counters[n].sample_groups was mistakenly streamed as an object, which
prevents having more than one, and goes against the published format
documentation.
The front-end was implemented to process the incorrect format, so it will need
to be updated as well; hence the version change to 18.
Differential Revision: https://phabricator.services.mozilla.com/D49867
--HG--
extra : moz-landing-system : lando
Instead of requesting profiles until it "seems" to have collected something,
use `nsIProfiler.waitOnePeriodicSampling()` to really wait for a sample to be
taken.
Note that this means some test could theoretically fail if they were in fact
waiting for stack samples to appear in the first registered thread. If that
happens, these tests should be udpated to do that extra wait-for-data.
Differential Revision: https://phabricator.services.mozilla.com/D50783
--HG--
extra : moz-landing-system : lando
`nsIProfiler.waitOnePeriodicSampling()` returns a promise that gets resolved
after the next full periodic sampling. The promise is rejected if the sampler is
not running.
Implementation detail: `Promise` uses single-threaded ref-counting, so special
care is needed not to touch it in the sampler thread. Safe ref-counting is
handled by `nsMainThreadPtrHolder` and `nsMainThreadPtrHandle`. And the promise
is only resolved/rejected on the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D50782
--HG--
extra : moz-landing-system : lando
Register a callback to be invoked the next time the Sampler thread ends its
periodic loop.
Registration may fail (e.g., if the profiler is not active), in which case the
callback is never called.
After successful registration the callback is guaranteed to be invoked after the
sampler runs, or stops running.
Differential Revision: https://phabricator.services.mozilla.com/D50781
--HG--
extra : moz-landing-system : lando
This patch updgrades the current version used in-tree so that browsertime works with chrome, it currently timesout with that browser.
Differential Revision: https://phabricator.services.mozilla.com/D50999
--HG--
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
Depends on D50466
reject-some-requires only supports require/lazyRequireGetter at the moment
We still have a few call sites for lazyImporter, even though they probably should be
migrated to lazyRequireGetter IMO.
Differential Revision: https://phabricator.services.mozilla.com/D50465
--HG--
extra : moz-landing-system : lando
The source of deadlock is due to profiler->lock->IO->interposer->profiler->lock
loops, where the second profiler call tries to lock the profiler mutex again.
Thanks to `profiler_is_locked_on_current_thread` the interposer can now check
whether the mutex is already locked, in which case it just won't call profiler
functions anymore, breaking the loop.
And now the profiler doesn't need to manually pause/resume/unregister the
(potential) interposer when doing I/Os.
Differential Revision: https://phabricator.services.mozilla.com/D50561
--HG--
extra : moz-landing-system : lando
PSMutex can store the id of the thread owning the lock, and it's safe to check
whether the current thread owns that lock (either it does and no-one else can
change it, or it's another id).
Comments related to memory hooks have been moved to memory_hooks.cpp, because
`profiler_is_locked_on_current_thread()` could be used for other things.
Differential Revision: https://phabricator.services.mozilla.com/D49895
--HG--
extra : moz-landing-system : lando
Refactored the recursion to improve its reliability, and added a caching layer.
Differential Revision: https://phabricator.services.mozilla.com/D50267
--HG--
extra : moz-landing-system : lando
The LUL unwinder on x86_64-android and x86_64-linux tries to read Dwarf unwind
information from the ELF section named ".eh_frame", and expects the section to
have type SHT_PROGBITS. It appears that that section might instead have the
type SHT_X86_64_UNWIND, possibly as a result of recent toolchain (linker?)
changes. This patch tracks that change.
Differential Revision: https://phabricator.services.mozilla.com/D50474
--HG--
extra : moz-landing-system : lando
Logging could be intercepted by the I/O interposer, which takes the lock, this
could deadlock if the mutex had already been taken in the same thread (e.g., by
a "locked" profiler function that wants to log something).
Now, functions that hold the lock must use `LOG_LOCKED(lock, ...)`, which will
skip logging when the I/O interposer is running.
In DEBUG builds, `LOG()` checks that the lock is not owned, to find possible
misuses.
`LOG()`s outside of platform.cpp were changed to `NS_WARNING`s, because they
could not access `gPSMutex` that's defined in platform.cpp; and they're really
warnings anyway.
Some interposer pauses/resumes have been relocated to more appropriate spots:
- Not needed around `locked_profiler_stream_json_for_this_process` anymore,
thanks to `LOG_LOCKED` inside.
- Definitely needed around `std::ofstream` operations in
`locked_profiler_save_profile_to_file`.
Differential Revision: https://phabricator.services.mozilla.com/D49896
--HG--
extra : moz-landing-system : lando
PSMutex can store the id of the thread owning the lock, and it's safe to check
whether the current thread owns that lock (either it does and no-one else can
change it, or it's another id).
Comments related to memory hooks have been moved to memory_hooks.cpp, because
`profiler_is_locked_on_current_thread()` could be used for other things.
Differential Revision: https://phabricator.services.mozilla.com/D49895
--HG--
extra : moz-landing-system : lando
A requested addition to the estimates in the preview pane, showing how large the requested set of tasks is compared to everyone else's set.
Differential Revision: https://phabricator.services.mozilla.com/D50076
--HG--
extra : moz-landing-system : lando
In Bug 1587907 we got some contentPid not found errors. It seemed like we were
failing intermittently at getting content pid. After moving test content inside
the BrowserTestUtils.withNewTab callback, we won't get the same error anymore.
Also from my testing, it looks like it makes the test execution faster. We were
getting some intermittents before because of the timeouts, these will be fixed
if my testing is correct.
Differential Revision: https://phabricator.services.mozilla.com/D49951
--HG--
extra : moz-landing-system : lando
Since markers are stored directly into the buffer:
- We don't need to wait for a sampling run to collect them,
- No markers are left uncollected between the last sampling and the time we stop
the profiler.
Differential Revision: https://phabricator.services.mozilla.com/D49233
--HG--
extra : moz-landing-system : lando
`stopProfilerAndGetThreads()` waits until at least one sample appears in the
main thread, before capturing a profile and stopping the profiler.
`stopProfilerNowAndGetThreads()` does not wait; this should be useful in tests
that may not generate any samples (e.g., using the nostacksampling feature).
Differential Revision: https://phabricator.services.mozilla.com/D49232
--HG--
extra : moz-landing-system : lando
Adds a test for Lintpref and two test files. Also makes some adjustments to `lintpref.yml` to improve support file loading.
Differential Revision: https://phabricator.services.mozilla.com/D49674
--HG--
extra : moz-landing-system : lando
Adds the filepaths of more pref files to Lintpref as well as to its TaskCluster entry. All of the pref files added are noted in bug 1585421.
Differential Revision: https://phabricator.services.mozilla.com/D49363
--HG--
extra : moz-landing-system : lando
Teaches Lintpref to look at `value` matches when considering possible duplicates.
Differential Revision: https://phabricator.services.mozilla.com/D49362
--HG--
extra : moz-landing-system : lando
Replaces the basic pattern-matching in the linter with a more robust regexp. This regexp can strip `name` and `value` from the pref, which will be useful in part 3 of bug 1587180.
Differential Revision: https://phabricator.services.mozilla.com/D49361
--HG--
extra : moz-landing-system : lando
Rather than statically loading the path to `all.js`, Lintpref should look at any file paths in `lintpref.yml`. Also added the `path` field to each error to accommodate multiple files, and a few other code tidiness cleanups.
Differential Revision: https://phabricator.services.mozilla.com/D48626
--HG--
extra : moz-landing-system : lando
The object-client.js file is now a proper protocol.js front,
but is still named after a client.
This is confusing, so we rename and move the file next to other
fronts, and update all consumers to the new terminology.
Differential Revision: https://phabricator.services.mozilla.com/D49878
--HG--
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-front.js
rename : devtools/shared/client/object-client.js => devtools/shared/fronts/object.js
extra : moz-landing-system : lando
Removes all of the duplicate prefs from mobile.js and StaticPrefList.yaml where the `value` field is the same. Carries over comments from mobile.js where needed.
Differential Revision: https://phabricator.services.mozilla.com/D49357
--HG--
extra : moz-landing-system : lando
The BuildReader's 'find_sphinx_variables' function is hardcoded to look for the
SPHINX_TREES and SPHINX_PYTHON_PACKAGE_DIRS variables. But it's otherwise
implemented to find any arbitrary variable (as long as they are a simple list
or dict).
This change simply moves the variable name(s) to the function call. The comment
about possibly wanted to use a higher level AST library to parse other kinds of
variables still applies, but for now this change is good enough to suit my
needs.
Differential Revision: https://phabricator.services.mozilla.com/D48424
--HG--
extra : moz-landing-system : lando
If 'fzf' was installed by mach, then check it's up to date and force update if needed.
Differential Revision: https://phabricator.services.mozilla.com/D49597
--HG--
extra : moz-landing-system : lando
