In the case of FramePointerStackwalk, the caller gives a pointer to the
top-most frame to walk from. There isn't really a reason to give a
number of frames to skip, as the right frame pointer could be given in
the first place if that was really necessary. And in practice, it's
hasn't been used so far.
In the case of MozStackWalkThread, the caller presumably doesn't know
what the thread the stack is being walked for is doing, and it would be
a guesswork to pass a valid number of frames to skip. In practice, it's
also not used.
The aSkipFrames is already a footgun on MozStackWalk (and we're going to
change that in bug 1515229), we don't need to keep a footgun on these
other stack walking methods.
Differential Revision: https://phabricator.services.mozilla.com/D108563
In a later bug, ExtractJsFrames will retrieve more information about the JS frames, which will be given to stack walkers in order to resume native sampling past JIT stacks.
Differential Revision: https://phabricator.services.mozilla.com/D108417
Some changes after the previous just-move-the-code refactoring:
- Updated functon comment for clarity.
- Renamed `jsCount` to more precise `jsFramesCount`.
- Moved `samplePosInBuffer` computation to where it's first needed. Bonus: It won't happen anymore if there is no JS stack.
- Construct `jsIter` as first `for` statement, it's clearer that it's the main loop iterator.
- Moved `MAX_JS_FRAMES` checks into the loop body, and only when needed.
- Try to move-from an rvalue reference to the `frame`, instead of `value()` forcing a copy.
- Moved `context` retrieval closer to first use. Same in `MergeStacks`; Note that `aRegisteredThread.GetJSContext()` is only reading a member variable, so it's cheap enough to use it again there if needed, it may even be better overall than storing it in a register or on the stack (if the compiler couldn't optimize it already before).
Differential Revision: https://phabricator.services.mozilla.com/D108416
Though the `mach` virtual environment is activated, it
hasn't been added to the `$PATH`. So, we can't use the
`$PATH` to find `glean_parser`.
Differential Revision: https://phabricator.services.mozilla.com/D106543
Add PerfStats::RecordMeasurement( metric, duration ) api so we can record timings for async metrics where details are not always known until completion.
Differential Revision: https://phabricator.services.mozilla.com/D107496
When "build targets" are used, the sccache server isn't
being used/integrated properly with make.
By moving rusttests to a separate build "application",
`client.mk` is invoked normally, and sccache is happy.
* Move rusttests to a new build "application".
* Move and denormalize rusttests mozconfigs. The new rusttests
mozconfigs should expand to be mostly identical to their old
versions, except with `MOZ_AUTOMATION_*=0` and
`--enable-application=tools/rusttests`.
They will differ a bit from their old variants because some
of them originally didn't source from their
respective `$app_mozconfigs/common`.
* Modify `baseconfig.mk` to change tiers if running rusttests.
* Adjust CI config to use new "rusttests" build application.
Differential Revision: https://phabricator.services.mozilla.com/D106294
Upstream wptserve just switched to Python 3 only. That's fine for
web-platform-tests, but it turns out that some marionette harness
tests are also using wptserve and are still on Python 2.
Since fixing marionette harness turns out to be non-trivial and this
blocks other wpt work, this patch does the following:
* Temporarily vendors the last wptserve revision that works with
Python 2 in to testing/web-platform/mozilla/tests/tools/wptserve_py2
* Configures the mach virtualenv to use that copy for Python 2 modules
only.
* Configures the test packaging system to also put that copy in the
common tests zip. Requirements files are updated to use either the
Python 2 version or the Pyhton 3 version as required.
Differential Revision: https://phabricator.services.mozilla.com/D106764
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
Use python3 in more places so we don't have to explicitly install
the python 2.x package.
The newer version of curl in 20.04 will hopefully fix the intermittent
http2 framing errors we've been seeing recently.
Differential Revision: https://phabricator.services.mozilla.com/D106259
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This patch wants to solve several quirks around the shutdown terminator.
- Use the same shutdown phase definitions in AppShutdown and nsTerminator. This touches quite a few files.
- Ensure that the terminator phase shift is handled before any shutdown observer notifications are sent and reduce its heartbeat duration.
- Add missing phases to the shutdown telemetry.
Please note that this changes the unit of "tick" to 100ms rather than 1s.
As a side effect, we also remove the obsolete "shutdown-persist" context.
While the existing test coverage continues to prove the most important functions, we acknowledge the wish for better test coverage with [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1693966 | bug 1693966 ]].
Differential Revision: https://phabricator.services.mozilla.com/D103626
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Conflicting pylint requirements were causing the new pip dependency resolver
to report an error. This updates the dependencies for pylint (using the hashin package)
so that the conflict is resolved.
Differential Revision: https://phabricator.services.mozilla.com/D106154
In XREMain(), if something went wrong between `PROFILER_INIT` and `MakeUnique<ScopedXPCOMStartup>()`,
- XPCOM would not be initialized -- Meaning `ExtensionPolicyService::GetSingleton()` would assert when not finding the Observer Service,
- But `gXPCOMShuttingDown` would still be false.
So `StreamMetaJSCustomObject` (invoked by `profiler_shutdown`, called by the `PROFILER_INIT` object destructor at the end of `XREMain()`) would still attempt to use `ExtensionPolicyService::GetSingleton()`.
In this patch, `StreamMetaJSCustomObject` now checks that the observer service exists, instead of only testing `!gXPCOMShuttingDown`. This should handle all situations where `ExtensionPolicyService::GetSingleton()` could assert, not just during normal shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D106061
This will reduce the false-positive rate that sometimes causes devs to
ignore other important warnings because they expect to see these
warnings because of module/legacy code styles.
```
if (foo) return; // no longer warns
if (bar)
return; // still warns
```
clang-format will sometimes turn long-line versions of the former into
the latter, and this warning will pick those as readability warnings.
NB: This is Chromium style for same-line conditional statements.
Another test result json has its EOL-newline removed too, since that's
what the script does and I'm just committing its results.
Differential Revision: https://phabricator.services.mozilla.com/D105497
No code changes.
Build issues were found by renaming `MOZ_GECKO_PROFILER` to something else in toolkit/moz.configure, in both unified and non-unified builds, on all supported platforms.
Also updated some profiler-related comments.
Differential Revision: https://phabricator.services.mozilla.com/D105375
