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
The fix in Bug 1577634 only worked for the beta channel as it didn't consider the RC case.
There's several situations:
* beta without comments --> beta with comments: handled by bug 1577634, but with fallout
* beta with comments --> beta with comments: `channel-prefs.js` is identical so we never need to apply any transforms
* beta with comments --> rc with comments: the channel changes in `channel-prefs.js` (by design) so we apply transforms
* rc with comments --> beta with comments: the channel changes in `channel-prefs.js` (by design) so we apply transforms
By moving the channel fixing transforms forward the file will become identical before we need to try the comment transform. The code breaks early in this case.
The release/esr case is simpler:
* release without comments --> release with comments: handled by comment transform, channel transforms only used for beta tests
* release with comments --> release with comments: `channel-prefs.js` already identical, no transforms applied
Differential Revision: https://phabricator.services.mozilla.com/D49224
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
This patch creates a new API to the nsIProfiler interface, through the activeConfiguration
property. It exposes the internal configuration of the profiler. In addition, this information
is serialized into the profile meta object.
Differential Revision: https://phabricator.services.mozilla.com/D48733
--HG--
extra : moz-landing-system : lando
We are not simply excluding all about:blanks because there might be some
about:blank that user really visits. But for others we don't want to include
the first about:blank because when a BrowsingContext is loaded, and if the
principal matches, the first document loaded in it will share the inner window.
Differential Revision: https://phabricator.services.mozilla.com/D47067
--HG--
extra : moz-landing-system : lando
We were keeping nsDocShell::mHistoryId and nsDocShell::mOSHE as keys. They
weren't quite good because:
1. While loading an iframe, they were being registered twice with the same
ids(for about:blank and the real URL) sometimes.
2. It wasn't possible to access to the parent mHistoryId and mOSHE from a child
processes if the parent is in a different process. That may not be the case for
now, but it will be after fission.
So we had to find other IDs to:
1. Determine the Tab of the frames.
2. Determine the URLs of the frames.
For the first use case, we were using nsDocShell::mHistoryId for that purpose
but that was wrong. The closest thing that we can get to a tab ID is
BrowsingContext ID because they don't change after a navigation. But iframes
have different BrowsingContext's, so we still need to create a tree to
construct a tab content. That can be either in the front-end or capture time.
For the second use case, we were using a key pair of mHistoryId and mOSHE. We
now chose to keep inner window IDs for that purpose. Inner window IDs are
unique for each navigation loads because inner window correspond to each JS
window global objects. That's why we can use that without any problem. But one
problem is that we cannot handle `history.pushState` and `history.replaceState`
changes with that change since window global objects won't change during those.
But that was the best thing we can do after fission. So this will be a small
sacrifice for us to keep that functionality working after fission.
In that patch we also remove the registration/unregistration calls. We are
going to add those calls in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D47065
--HG--
extra : moz-landing-system : lando
Having `mProfileBuffer` be a pointer is not really helpful:
- The pointer is never null (It's allocated on ActivePS construction, and
implicitly deleted on ActivePS destruction); it's never moved-from.
- It requires an extra `new` and an extra `delete`.
Differential Revision: https://phabricator.services.mozilla.com/D48650
--HG--
extra : moz-landing-system : lando
Add assertions that all `sInstance` pointers (from both `CorePS` and `ActivePS`)
are not null before being dereferenced.
This is probably more than needed, but it's only `MOZ_ASSERT`s limited to
Nightly, and it should give better feedback in case something goes wrong.
Eventually, I think it would be better to make most methods non-static, and have
a checked reference-to-instance getter.
Differential Revision: https://phabricator.services.mozilla.com/D48649
--HG--
extra : moz-landing-system : lando
The duration file downloader uses the cache directory created by taskgraph generation.
Differential Revision: https://phabricator.services.mozilla.com/D48705
--HG--
extra : moz-landing-system : lando
This should fix the doc builds on Windows, as sphinx-js added Windows support in 2.3.1 and 2.4. We also now get support for variadic args, @deprecated, and @see, along with other features.
sphinx-js 2.7.1 changed the default cwd to be the one containing conf.py, so I also had to twiddle `jsdoc_config_path`.
Let some other pipenv pinnings update themselves as well, as, if I don't, they'll just update themselves the next time somebody runs `mach doc`, dirtying their tree.
I suspect this also fixes bug 1556460, whose equivalent bug in sphinx-js is https://github.com/mozilla/sphinx-js/issues/106. IOW, it should no longer break with versions of jsdoc >= 3.6.
Differential Revision: https://phabricator.services.mozilla.com/D48122
--HG--
extra : moz-landing-system : lando
Test more of the ProfilerMarkerPayload's, all those from ProfilerMarkerPayload.h
that did not require external structures. (More to be added in the future.)
These tests focus on the profiler, by simulating markers as we expect them, and
verifying that the corresponding output is correct JSON as expected by the
frontend.
Differential Revision: https://phabricator.services.mozilla.com/D48327
--HG--
extra : moz-landing-system : lando
This does not test more markers than before. But instead of searching for
strings in the raw json, expected values are checked in the parsed output
profile.
Also some `ASSERT_...` tests could be changed to `EXPECT_...`, because their
failures would not prevent running more of the test.
Differential Revision: https://phabricator.services.mozilla.com/D48326
--HG--
extra : moz-landing-system : lando
This does many things:
1) stops producing (and consuming) `FennecJNI*` JNI wrappers
2) removes the :app and :thirdparty Gradle projects
3) removes relevant pieces of the Gradle target configuration
4) updates lints
5) purges old configurations
After this commit, the `mobile/android` project/application builds
only GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D46536
--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
This should fix the doc builds on Windows, as sphinx-js added Windows support in 2.3.1 and 2.4. We also now get support for variadic args, @deprecated, and @see, along with other features.
sphinx-js 2.7.1 changed the default cwd to be the one containing conf.py, so I also had to twiddle `jsdoc_config_path`.
Let some other pipenv pinnings update themselves as well, as, if I don't, they'll just update themselves the next time somebody runs `mach doc`, dirtying their tree.
I suspect this also fixes bug 1556460, whose equivalent bug in sphinx-js is https://github.com/mozilla/sphinx-js/issues/106. IOW, it should no longer break with versions of jsdoc >= 3.6.
Differential Revision: https://phabricator.services.mozilla.com/D48122
--HG--
extra : moz-landing-system : lando
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
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