The Wasm profiling frame iterator uses the return address in the LR register when
interrupting during the prologue. The Linux/Android code was correctly initializing it,
but on Mac and Windows we always used 0.
Differential Revision: https://phabricator.services.mozilla.com/D152268
What we are doing:
Adding a contact section in auto-generated performance testing docs so people know who to contact when they are having an issue with a given module/component
Differential Revision: https://phabricator.services.mozilla.com/D151400
Instead of trying to create a too-big shmem, or if the shmem creation fails,
send a short message starting with '*', which the parent can put into the
profileGatheringLog.
Differential Revision: https://phabricator.services.mozilla.com/D152028
Instead of trying to send a too-big message, send a short message starting
with '*', which the parent can put into the profileGatheringLog.
Note: The `CollectProfileOrEmptyString` is now only used by GrabShutdownProfile
(it was previously also used by RecvGatherProfile before it went async). Since
this patch is completely changing its implementation, we may as well fold it
back into its only caller.
Differential Revision: https://phabricator.services.mozilla.com/D152027
Instead of throwing away the whole profile at the end if it's too big, we try
to keep as much data as possible, by only throwing away incoming child profiles
that would make the resulting combined full profile too big.
Differential Revision: https://phabricator.services.mozilla.com/D152026
Instead of allocating a buffer with the profile and then copying it into an
nsCString (at which point there are two full copies in memory), we resize the
nsCString as needed and directly output the profile data into it.
Differential Revision: https://phabricator.services.mozilla.com/D152025
The promise to be resolved may end up in JavaScript, so we check for the
maximum JS string length -- which is under the nsCString max length, so we
won't fail the too-big-string assertion there.
Differential Revision: https://phabricator.services.mozilla.com/D152024
This will be used in the following patches to more easily reject the promise
with a specific code AND reset gathering, in one call.
Differential Revision: https://phabricator.services.mozilla.com/D152023
This may be useful to advanced profiler users, to see how the multi-process
profile gathering went.
(Some information, like missing processes, could be useful to expose to all
users, but this should be done in future tasks, with corresponding front-end
work.)
Note: There are no direct tests, as this is intended for advanced human users,
and the format is not guaranteed to stay stable.
Differential Revision: https://phabricator.services.mozilla.com/D151902
This log goes into `profile.profilingLog[<parent pid>].bufferGlobalController.updates`, an array of data arrays.
See the related `updatesSchema` for what's in those data arrays.
Note: There are no direct tests, as this is intended for advanced human users,
and the format is not guaranteed to stay stable.
Differential Revision: https://phabricator.services.mozilla.com/D151776
What we are doing:
Giving the fuzzy selector used in the compare selector --full as an option
Why:
By using --full we expand the test list available to the compare selector, and allow all tasks to be run. Without --full we only see a common subset of tasks typically run on moz-central
How we did this:
We are adding in the common_groups = ["task"] line which allowed fuzzy to be run with a general set of args of which one is --full
Differential Revision: https://phabricator.services.mozilla.com/D151837
When converting lazy getter calls, if the previous/next statement is
`ChromeUtils.defineESModuleGetters`, add properties into it, instead of
converting the lazy getter call into `ChromeUtils.defineESModuleGetters`
or creating new `ChromeUtils.defineESModuleGetters` call.
Differential Revision: https://phabricator.services.mozilla.com/D151980
This revision migrates all the content of the following modules:
- Desktop_Firefox
- Toolkit
- Core
- Testing
Up to the their state on Monday June 20th, 2022 in the old system.
The rst file was automatically generated by running `mots export`.
Differential Revision: https://phabricator.services.mozilla.com/D130508
When reading Dwarf unwind info, `CallFrameInfo::State::DoInstruction` is
called once per CFI instruction. At both call sites, the call is driven by a
simple loop. Because each call doesn't do much work, the call overhead is
quite high, and there are huge numbers of CFI instructions to be processed.
This patch moves the loop into its own method `DoInstructions`, and adds
annotations in the hope of getting `DoInstruction` inlined into the loop.
On an Intel Core i5 1135G7 at circa 4 GHz, this reduces the Dwarf read time
from 0.27 seconds (after bugs 1754932, 1777540 and 1777949 have landed) to
0.26 seconds. Not much of a win, but on the other hand, the insn count falls
from 3906 million to 3640 million, which seems like a worthwhile win for what
is a trivial change.
Differential Revision: https://phabricator.services.mozilla.com/D151262
This profilingEndTime is the time when this property is actually written, which
corresponds to the end of the profiling session.
If it's a shutdown profile, the exact same time is used for the existing
`meta.shutdownTime` property.
Depends on D151355
Differential Revision: https://phabricator.services.mozilla.com/D151356
This contentEarliestTime is the time when the earliest (and oldest) surviving
chunk was prepared to start receiving data.
It should be a good hint to the front-end about where the profiling data
actually starts.
Differential Revision: https://phabricator.services.mozilla.com/D151355