This also adds a commented out option for automatically fixing use-services in the ESLint rule. This cannot be enabled at the moment as it needs special treatment for chrome tests.
Differential Revision: https://phabricator.services.mozilla.com/D124391
We've overloaded "bootstrap" to mean three different things:
* The "standalone bootstrap script": `python/mozboot/bin/bootstrap.py`.
This is to freshly clone a new repo, then run `./mach bootstrap`.
* `./mach bootstrap`: Install necessary dependencies and set up the
system for development.
* "Mach bootstrap": do the in-process initialization work Mach needs
before it can run commands.
By using the term "initialize" instead, perhaps we can remove
ambiguity when discussing Mach.
I'm not attached to the name (or this change at all), but I'm interested
in reviewer thoughts :)
Differential Revision: https://phabricator.services.mozilla.com/D120410
This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153
The lock in the inner `profiler_suspend_and_sample_thread` function was only needed on the `!aIsSynchronous` code path.
So instead, the pointer to the lock is passed in this case, otherwise `nullptr` indicates a synchronous (same-thread) sampling.
Differential Revision: https://phabricator.services.mozilla.com/D123915
Since bug 1722261, thread registrations are not tied to CorePS anymore, ThreadRegistry stores them in a static list.
Also, profiler_register_thread immediately calls ThreadRegistration::RegisterThread -> ThreadRegistration constructor -> ThreadRegistry::Register, which checks if there is a CorePS before working with it.
So this assertion can safely be removed now.
In rare instances, `CorePS` may not actually exist (profiler not initialized yet, or already shutdown), and this assertion could trigger and report an unimportant crash.
Differential Revision: https://phabricator.services.mozilla.com/D123912
The buffer was previously allocated as soon as a JSContext was present, meaning that some memory was used even when the profiler was not running, which is the case most of the time for most users.
This saves some memory, at the cost of having to lock the per-thread ThreadRegistration data when sampling a thread with a JSContext. This should have low contention risk, because it's mostly used when sampling on the thread, while the periodic sampler uses its own buffer so it doesn't need to lock the per-thread data.
Differential Revision: https://phabricator.services.mozilla.com/D123910
Running the profiler while Firefox runs in rr sometimes crashes, and it seems the SP register is far from the known stack area (ending at StackTop), which then proceeds to copy some protected memory.
Note that there was already a `start < end` test, this patch adds an equivalent test on the other side, allowing for a 1MB stack size. Observed stacks during quick testing were up to around 520KB, and the crashing rr case was in the trillions(!), so 1MB should be an appropriate number that should catch "wrong" SPs while allowing real stacks.
Differential Revision: https://phabricator.services.mozilla.com/D123605
When starting the profiler, also make a copy of the filter strings
converted to lower-case. This allows caseless comparisons to be made
against thread names without repeatedly converting the filters to
lower-case for each thread.
Differential Revision: https://phabricator.services.mozilla.com/D123302
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
`profiler_capture_backtrace_into` now only uses thread-safe functions: ThreadRegistration::WithOnThreadRefOf, Register::SyncPopulate, DoSyncSample.
So we don't need to lock the main profiler mutex anymore.
This means that on-thread sampling (typically used in markers) can happen at the same time the periodic sampler has locked the profiler mutex and is sampling this and other threads.
Differential Revision: https://phabricator.services.mozilla.com/D122089
Since these functions don't need to access profiler functions requiring a lock, they themselves don't need that lock anymore.
Differential Revision: https://phabricator.services.mozilla.com/D122088
MergeStack requires a fairly large buffer to store JS frames, too big to be allocated on the stack without risking a stack overflow.
Until now, there was only one buffer, stored in CorePS, and only accessible while holding the Profiler gPSMutex.
Now each thread that has a JSContext, also has its own JS frame buffer, which is accessible on the thread without needing any lock.
The Profiler's Sampler still uses the CorePS buffer for its periodic sampling, but it won't prevent parallel on-thread sampling anymore.
The appropriate buffer is passed to ExtractJsFrames and then MergeStacks.
MergeStacks accepts a null pointer, which happens on threads where there is no JSContext, and therefore no JS to sample.
Differential Revision: https://phabricator.services.mozilla.com/D122087
All implementations of DoNativeBacktrace are now thread-safe, so it's not necessary to make their use dependent on the Profiler's gPSMutex being locked.
Differential Revision: https://phabricator.services.mozilla.com/D122085
`Registers::SyncPopulate()` now uses a ucontext_t that's stored with the `Registers` object, so it can safely be called from parallel threads.
Differential Revision: https://phabricator.services.mozilla.com/D122083
`profiler_capture_backtrace_into` now only uses thread-safe functions: ThreadRegistration::WithOnThreadRefOf, Register::SyncPopulate, DoSyncSample.
So we don't need to lock the main profiler mutex anymore.
This means that on-thread sampling (typically used in markers) can happen at the same time the periodic sampler has locked the profiler mutex and is sampling this and other threads.
Differential Revision: https://phabricator.services.mozilla.com/D122089
Since these functions don't need to access profiler functions requiring a lock, they themselves don't need that lock anymore.
Differential Revision: https://phabricator.services.mozilla.com/D122088
MergeStack requires a fairly large buffer to store JS frames, too big to be allocated on the stack without risking a stack overflow.
Until now, there was only one buffer, stored in CorePS, and only accessible while holding the Profiler gPSMutex.
Now each thread that has a JSContext, also has its own JS frame buffer, which is accessible on the thread without needing any lock.
The Profiler's Sampler still uses the CorePS buffer for its periodic sampling, but it won't prevent parallel on-thread sampling anymore.
The appropriate buffer is passed to ExtractJsFrames and then MergeStacks.
MergeStacks accepts a null pointer, which happens on threads where there is no JSContext, and therefore no JS to sample.
Differential Revision: https://phabricator.services.mozilla.com/D122087
All implementations of DoNativeBacktrace are now thread-safe, so it's not necessary to make their use dependent on the Profiler's gPSMutex being locked.
Differential Revision: https://phabricator.services.mozilla.com/D122085
`Registers::SyncPopulate()` now uses a ucontext_t that's stored with the `Registers` object, so it can safely be called from parallel threads.
Differential Revision: https://phabricator.services.mozilla.com/D122083
Instead of blindly outputting floating-point numbers of milliseconds, which leads to things like 363.03499999999997, times in ms are now converted to integer number of nanoseconds, stringified, and then manually adjusted to milliseconds again, so we get smaller and friendlier outputs like 363.035.
Eventually, bug 1726675 may change all times to integer number of nanoseconds anyway, but this patch is already helpful in reducing the output, and paves the way by separating the time-output functions from other number outputs.
Differential Revision: https://phabricator.services.mozilla.com/D123329
The purpose of this is to remove as many docstrings from CommandProvider
classes to make the step of moving commands out of classes simpler.
Where possible, the docstring has been moved to or merged with the function.
Differential Revision: https://phabricator.services.mozilla.com/D123288
It's more appropriate because the running times are only relevant to a profiling session.
And PreviousThreadRunningTimes can now be accessed through the ThreadRegistration (thanks to the ProfiledThreadData pointer added in the previous patch).
Since the threads' RunningTimes don't live in `PlatformData`, and because they are now implicitly cleared between profiling sessions (because `ProfiledThreadData`s get destroyed/recreated when stopping/starting the profiler), there is no need for an explicit `ClearRunningTimes()` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121964
Because ProfiledThreadData is always related to IsBeingProfiled, they are set and cleared together.
In particular, this is used to quickly guess that the thread is being profiled by reading the non-atomic mProfiledThreadData, rather than reading the slightly slower atomic mIsBeingProfiled.
Differential Revision: https://phabricator.services.mozilla.com/D121963
This is mostly a copy of the old PlatformData. That old PlatformData will be removed in a later patch, once it's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121959
This will help with replacing the old {,Racy}RegisteredThread with the new ThreadRegistration classes, while still being able to access the old classes (until they are not needed anymore).
Differential Revision: https://phabricator.services.mozilla.com/D121849
Now {,Racy}RegisteredThread don't contain any data, but provide the same API that goes through ThreadRegistration.
Until they are removed, {,Racy}RegisteredThread are given private access to ThreadRegistration{,Data} for easier access.
This means that we can now change uses of RegisteredThread to use ThreadRegistration directly instead, and the data will be the same through either APIs.
Also, RacyRegisteredThread::ThreadId() was unused so it can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D121847
The ProfilingStack object inside ThreadRegistrationData is guaranteed to live while the thread is registered (and alive), and all accesses are guaranteed to be done either:
- On-thread, so during that time ThreadRegistrationData and its ProfilingStack cannot be destroyed.
- From another thread, but with the Profiler lock and/or per-thread lock, which also guarantees that ThreadRegistrationData and its ProfilingStack cannot be destroyed.
RacyRegisteredThread brought some doubts about end-of-thread accesses, that why there's was an intermediate ref-counted ProfilingStackOwner to keep ProfilingStack alive where needed. Now we can remove it.
Also the separate TLS (Thread Local Storage) for ProfilingStackOwner can be removed, since we can reach the ProfilingStack through the ThreadRegistration TLS for the same cost.
Differential Revision: https://phabricator.services.mozilla.com/D121846
Since ThreadRegistration already handles nested registrations, the legacy profiler_{,un}register_thread() functions don't need to care about that anymore (and the RegisteredThread TLS will be removed in a later patch anyway).
The informational markers have been moved to ProfilerThreadRegistration.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D122315
ProfilerThreadRegistry (un)register functions have been moved to platform.cpp because they need to interact closely with functions and classes in that file.
profiler_{,un}register_thread are now simple calls to ThreadRegistration::{R,Unr}egisterThread, which call ThreadRegistry::{R,Unr}egister, which now integrate that old bodies of profiler_{,un}register_thread.
So from this point, threads may use either profiler_{,un}register_thread or ThreadRegistration equivalents, and this will (un)register with both the new ThreadRegistration classes and the legacy RegisteredThread class into CorePS. (Later patches will remove RegisteredThread completely.)
Bonus: Since the stack top is now adjusted when constructing ThreadRegistrationInfo (before giving it to the legacy ThreadInfo), there is no more need for `GetStackTop()`.
Differential Revision: https://phabricator.services.mozilla.com/D121844
Thread-related APIs that are currently in ProfilerState.h will move here, and will use the new ThreadRegistration classes introduced in bug 1721939.
In this patch the header is empty apart from a few #includes, and users of "ProfilerState.h"'s thread functions now #include "ProfilerThreadState.h" instead. So there are no actual code changes yet.
Differential Revision: https://phabricator.services.mozilla.com/D121843
When a `ThreadRegistration` object is created through `ThreadRegistration::RegisterThread` (instead of directly on the stack), this is recorded in `mIsOnHeap`.
This helps better handle incorrectly-nested registration/unregistration pairs, or excess unregistrations.
Also, markers are now generated to highlight extra (un)registrations, with added backtrace for those surprising cases of excess unregistrations that should probably be reworked.
And `ThreadRegistration::GetTLS()` was simplified, so it auto-initializes when first used, instead of relying on the main thread registration.
Differential Revision: https://phabricator.services.mozilla.com/D123229
Sampling overheads are very rarely useful, but they occupy some space during profiling, but also a lot of space in the final JSON profile.
So now they will only be recorded if the environment variable "MOZ_PROFILER_RECORD_OVERHEADS" is set to any non-empty value.
Differential Revision: https://phabricator.services.mozilla.com/D123303
This ensures our users will use the latest version of the frontend when
capturing 'cancel' network markers.
Depends on D123254
Differential Revision: https://phabricator.services.mozilla.com/D123255
This patch supports channel cancelations with network markers.
Because of all the possible ways to stop a channel and hence all
possible end markers, it also introduces a new boolean to reduce the
complexity. Indeed it happens that 2 "end functions" are called, but we
need to insert only 1 end marker to have a well-formed result in the
Profiler frontend.
Differential Revision: https://phabricator.services.mozilla.com/D122111
It's more appropriate because the running times are only relevant to a profiling session.
And PreviousThreadRunningTimes can now be accessed through the ThreadRegistration (thanks to the ProfiledThreadData pointer added in the previous patch).
Since the threads' RunningTimes don't live in `PlatformData`, and because they are now implicitly cleared between profiling sessions (because `ProfiledThreadData`s get destroyed/recreated when stopping/starting the profiler), there is no need for an explicit `ClearRunningTimes()` anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121964
Because ProfiledThreadData is always related to IsBeingProfiled, they are set and cleared together.
In particular, this is used to quickly guess that the thread is being profiled by reading the non-atomic mProfiledThreadData, rather than reading the slightly slower atomic mIsBeingProfiled.
Differential Revision: https://phabricator.services.mozilla.com/D121963
This is mostly a copy of the old PlatformData. That old PlatformData will be removed in a later patch, once it's not used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D121959
This will help with replacing the old {,Racy}RegisteredThread with the new ThreadRegistration classes, while still being able to access the old classes (until they are not needed anymore).
Differential Revision: https://phabricator.services.mozilla.com/D121849
Now {,Racy}RegisteredThread don't contain any data, but provide the same API that goes through ThreadRegistration.
Until they are removed, {,Racy}RegisteredThread are given private access to ThreadRegistration{,Data} for easier access.
This means that we can now change uses of RegisteredThread to use ThreadRegistration directly instead, and the data will be the same through either APIs.
Also, RacyRegisteredThread::ThreadId() was unused so it can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D121847
The ProfilingStack object inside ThreadRegistrationData is guaranteed to live while the thread is registered (and alive), and all accesses are guaranteed to be done either:
- On-thread, so during that time ThreadRegistrationData and its ProfilingStack cannot be destroyed.
- From another thread, but with the Profiler lock and/or per-thread lock, which also guarantees that ThreadRegistrationData and its ProfilingStack cannot be destroyed.
RacyRegisteredThread brought some doubts about end-of-thread accesses, that why there's was an intermediate ref-counted ProfilingStackOwner to keep ProfilingStack alive where needed. Now we can remove it.
Also the separate TLS (Thread Local Storage) for ProfilingStackOwner can be removed, since we can reach the ProfilingStack through the ThreadRegistration TLS for the same cost.
Differential Revision: https://phabricator.services.mozilla.com/D121846
Since ThreadRegistration already handles nested registrations, the legacy profiler_{,un}register_thread() functions don't need to care about that anymore (and the RegisteredThread TLS will be removed in a later patch anyway).
The informational markers have been moved to ProfilerThreadRegistration.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D122315
ProfilerThreadRegistry (un)register functions have been moved to platform.cpp because they need to interact closely with functions and classes in that file.
profiler_{,un}register_thread are now simple calls to ThreadRegistration::{R,Unr}egisterThread, which call ThreadRegistry::{R,Unr}egister, which now integrate that old bodies of profiler_{,un}register_thread.
So from this point, threads may use either profiler_{,un}register_thread or ThreadRegistration equivalents, and this will (un)register with both the new ThreadRegistration classes and the legacy RegisteredThread class into CorePS. (Later patches will remove RegisteredThread completely.)
Bonus: Since the stack top is now adjusted when constructing ThreadRegistrationInfo (before giving it to the legacy ThreadInfo), there is no more need for `GetStackTop()`.
Differential Revision: https://phabricator.services.mozilla.com/D121844
Thread-related APIs that are currently in ProfilerState.h will move here, and will use the new ThreadRegistration classes introduced in bug 1721939.
In this patch the header is empty apart from a few #includes, and users of "ProfilerState.h"'s thread functions now #include "ProfilerThreadState.h" instead. So there are no actual code changes yet.
Differential Revision: https://phabricator.services.mozilla.com/D121843
plugin-syntax-class-properties was supported by default in Babel 7.14.0.
This also adds top level await support in modules with the upgrade to Babel 7.15.0.
Differential Revision: https://phabricator.services.mozilla.com/D122865
The majority of RunningTimes objects would contain zero or near-zero values (no/low activity), so it makes sense to serialize them using ULEB128, which only takes 1 bytes for values under 128, instead of the full 8 bytes.
And high values in the millions would still serialize in 4 bytes or less, half of the 8-byte type size.
This patch is particularly useful now, because `SampleSample` entries are much smaller than `CompactStack` entries, so the size taken by RunningTimes is much more significant now, and saving up to 7 bytes means we could record up to 24% more of these entries in the same buffer space.
Differential Revision: https://phabricator.services.mozilla.com/D122680
Instead of copying the full stack from the previous sample when identical, the new ProfileBufferEntryKind::TimeBeforeSameSample + SameSample entry pair indicates that this is an identical sample. Later when producing the final JSON profile, we can just re-use the same sample identifier as before.
This effectively lowers the size of this kind of entry from hundreds of bytes, down to 20-30 bytes, which should help with capturing more samples in the same buffer size. And it also uses less CPU resources, since we don't need to find the previous stack and copy it.
We still need to perform a full copy at the start of a buffer chunk, to make sure there is always a full stack available in case older previous chunks have been destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D122679
We passed 64-bit integer arguments, but `AppendPrintf` took them
as 32-bit parameters. This generated a wrong version string in
32bit build.
Differential Revision: https://phabricator.services.mozilla.com/D122623
`mozilla::profiler::ThreadRegistry` keeps a list of all `ThreadRegistration`s, and makes it safely accessible from any thread.
While a thread is accessing the list, that list cannot be changed (a thread (un)registering itself needs to acquire the associated mutex). In particular, a thread will not disappear during that time, so it's safe to access the `ThreadRegistration` data that is owned by these threads.
The subset of `ThreadRegistrationData` accessor sub-classes available through `ThreadRegistry` is different from direct on-thread access, to guarantee safe access in different circumstances.
For example, `JSContext` may be read through a `LockedRWFromAnyThread`, which requires the per-thread lock, thereby preventing any simultaneous `JSContext` change from the owning thread. And because the `LockedRWOnThread` accessor is not reachable through the registry, it's not allowed, or even possible, to change `JSContext` from other threads.
Differential Revision: https://phabricator.services.mozilla.com/D120818
This class is how a thread will register itself, and contains the thread's relevant data.
A registration-accessor object can be accessed on the thread with `GetOnThreadPtr()` or `WithOnThreadRef{,Or}()`, and from there some of the data accessor may be obtained, with per-thread lock where necessary.
(The next patch will introduce ThreadRegistry to access registrations from other threads.)
Differential Revision: https://phabricator.services.mozilla.com/D120817
Non-virtual sub-classes of `ProfilerThreadRegistrationData` provide layers of public accessors to subsets of the data.
Each level builds on the previous one and adds further access to more data, but always with the appropriate guards where necessary.
These classes have protected constructors, so only some trusted classes (in later patches) will be able to construct them, and then give limited access depending on who asks (the owning thread or another one), and how much data they actually need.
The hierarchy is, from base to most derived:
- `ThreadRegistrationData` (previous patch)
- `ThreadRegistrationUnlockedConstReader`
- `ThreadRegistrationUnlockedConstReaderAndAtomicRW`
- `ThreadRegistrationUnlockedRWForLockedProfiler`
- `ThreadRegistrationUnlockedReaderAndAtomicRWOnThread`
- `ThreadRegistrationLockedRWFromAnyThread`
- `ThreadRegistrationLockedRWOnThread`
- `ThreadRegistration::EmbeddedData` (next patch, as data member of `ThreadRegistration`)
Tech detail: These classes need to be a single hierarchy so that the upcoming `ThreadRegistration` class can contain the most-derived class, and from there can publish references to base classes without relying on Undefined Behavior. (It's not allowed to have some object and give a reference to a sub-class, unless that object was *really* constructed as that sub-class at least, even if that sub-class only adds member functions!)
And where appropriate, these references will come along with the required lock.
For example:
JSContext can only be written on the owning thread, through `ThreadRegistrationLockedRWOnThread` (which will be accessed through TLS = Thread Local Storage), which requires a per-thread lock.
Thanks to that, JSContext can be read using `ThreadRegistrationUnlockedReaderAndAtomicRWOnThread`, without lock because we're on the owning thread, so there cannot be any write at the same time.
Other threads will be able to read it as well, but they will only see it through `ThreadRegistrationLockedRWFromAnyThread`, which will require the per-thread lock, thereby preventing simultaneous writes.
Differential Revision: https://phabricator.services.mozilla.com/D120816
This class contains the same data as was in `RacyRegisteredThread` and `RegisteredThread`, but this data is kept `protected`, accessors will be added through sub-classes in the next patch, and tests in a later patch once publicly accessible.
Note that `ThreadRegistrationInfo`, `ProfilingStack`, and `PlatformData` are now directly included as values.
The stack top platform-specific code was taken from `GetStackTop()` in platform-win32.cpp and platform-macos.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D120815
This class will contain platform-specific data about threads.
It needs to be public because it will be included as value into the thread registration data (to avoid a separate allocation).
Tests will be added when platform-specific code is implemented in bug 1722261.
Differential Revision: https://phabricator.services.mozilla.com/D120814
`ProfilerThreadRegistrationInfo` will replace `ThreadInfo`, and contains thread-specific information that may be kept after that thread has ended, to identify recorded profiling data about that thread.
It is public and not ref-counted because it will be included as value into the thread registration data (to avoid a separate allocation).
Differential Revision: https://phabricator.services.mozilla.com/D120813
This hides the scProfilerMainThreadId detail, and makes for a safer API.
Also, ::profiler_init_main_thread_id() calls ::mozilla::baseprofiler::profiler_init_main_thread_id().
And in non-MOZ_GECKO_PROFILER builds, AUTO_PROFILER_INIT calls profiler_init_main_thread_id(), which makes other main-thread functions usable there (assuming profiler_current_thread_id works).
Differential Revision: https://phabricator.services.mozilla.com/D121695
This patch only shuffles source code around, so that all declarations in {,Base}ProfilerUtils.h are now implemented only in ProfilerUtils.cpp (instead of the different platform-*.cpp), the final generated code should be the same in MOZ_GECKO_PROFILER builds (the default on all our supported platforms).
This simplifies the headers and makes further changes easier.
In non-MOZ_GECKO_PROFILER builds: On supported platforms these functions are now fully defined; Unsupported platforms should all had `getpid()`, but thread ids are null.
So now `profiler_current_process_id()` is available on all platforms, at all tier levels.
Differential Revision: https://phabricator.services.mozilla.com/D121051
Since ProfilerProcessId and ProfilerThreadId (and their NumberTypes) will potentially grow to 64 bits on some platforms (in a later patch), all code that uses them must be able to handle bigger types.
Differential Revision: https://phabricator.services.mozilla.com/D121049
We are using the OS version as reported in the user agent string, but on macOS the version is capped at 10.15. This patch now reports the real and full OS version.
Differential Revision: https://phabricator.services.mozilla.com/D122063
This makes all our stackwalkers in Firefox consistent with respect to return addresses:
For non-leaf frames in stacks, the code address now always points to the instruction
*after* the call instruction, i.e. to the instruction that will be executed once the
function returns.
For symbolication purposes, 1 byte will need to be subtracted in order to obtain correct
line number + inline stack information for the call instruction. This subtraction will
be the responsibility of the Firefox profiler front-end, not of the stackwalkers.
Depends on D121930
Differential Revision: https://phabricator.services.mozilla.com/D121931
This will make it so that, for return addresses, symbolication can look up
the address "returnAddress - 1" and get the correct line number (and inline
stack) for the call instruction.
Without the masking, returnAddress - 1 might still fall into the instruction
*after* the call instruction, giving wrong line numbers / inline stacks.
Differential Revision: https://phabricator.services.mozilla.com/D121930
When mfplat.dll loads msvp9dec_store.dll, it posts a task
to unload the module to the work queue even if msvp9dec_store.dll
is already loaded and mfplat.dll skips LoadLibrary. Therefore,
we cannot safely lock msvp9dec_store.dll by loading it as data.
The proposed fix is to skip processing the module.
Differential Revision: https://phabricator.services.mozilla.com/D121777
This is a prerequisite for adding a marker API. There is the same API for C++
as `profiler_can_accept_markers`. This API can both be used as an external API
before adding an expensive payload to the profile marker, and it can be used as
an internal function to check it inside the new `add_marker` API that will be
introduced soon.
Differential Revision: https://phabricator.services.mozilla.com/D121535
This is a syntactic sugar for `gecko_profiler_label` API. When you use this
macro on top of a function, it will automatically expand the function content
with `gecko_profiler_label` macro call.
Differential Revision: https://phabricator.services.mozilla.com/D120794
Bindgen will be needed for gecko_profiler::is_active gecko_profiler_label API
in this patch, as well as the marker API that will land after this.
Differential Revision: https://phabricator.services.mozilla.com/D120789
This moves the adding of the end marker for redirects in nsHttpChannel
to SetupReplacementChannel, so that all redirects are properly caught.
Without that, some requests will show as unfinished in the profiler
frontend.
Some of the redirects are internal and we may be able to flag and ignore
them in the frontend, but that's work for the future.
Because all redirections get a "REDIRECT" end marker, including the
internal redirection to the service worker's intercepted channel, we now
need an additional "START" marker there as well.
All existing profiler tests related to service workers needed to be
updated because there's an extra redirect marker in all these requests,
as well as several pairs of markers that all have the same id.
This also adds a new profiler test for handling the http->https case
that we wouldn't catch before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D118836
Now that PortLink is the only MessageLink implementation, it is no longer
necessary to support sharing a single `RefCountedMonitor` between multiple
MessageChannels, meaning that we can construct the monitor directly in the
`MessageChannel` constructor. The monitor still needs to be refcounted due to
being used by the PortLink as part of the listener implementation.
Differential Revision: https://phabricator.services.mozilla.com/D119350
The only platforms available for devtools chrome & browser mochitests are now:
- shippable
- asan
- qr
Only qr covers debug/opt/fission, so let's use this.
Differential Revision: https://phabricator.services.mozilla.com/D120580
These classes should replace the `int` type that is currently used to store process and thread ids. The next patches will start using them. Advantages:
- Prevent type mismatches, e.g., giving a process id (or other number) to a function expecting a thread id.
- Prevent nonsensical arithmetic operations.
- Make the unspecified id more abstract, so it's more obvious and portable.
- Make conversions to/from numbers (for display or storage) more visible.
- Allow future changes of APIs using them less risky.
- Allow future changes of the ids themselves (e.g., to be able to use bigger underlying types on some platforms, or even the opaque std:🧵:id type.)
Differential Revision: https://phabricator.services.mozilla.com/D120221
This new header isolates the process and thread functions that should be available in all builds, and in most other profiler headers.
Non-MOZ_GECKO_PROFILER implementations return ids 0 (unspecified process/thread). `profiler_is_main_thread()` returns false, it's arbitrary but consistent with `0` (it makes little sense to use it there anyway.)
Differential Revision: https://phabricator.services.mozilla.com/D120220
The next patch will extract parts of these headers into a separate file, so it's best to do this clean-up now, to best preserve history.
- Add [[nodiscard]] to all functions that return something. (There are no cases where that returned value could really be ignored.)
- Hide scProfilerMainThreadId in a "detail" namespace, to emphasize that it's an implementation detail that the user shouldn't access directly.
- Combine tightly-nested namespaces start/end into single lines, it's more readable.
Differential Revision: https://phabricator.services.mozilla.com/D120219
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
This prevents unwanted direct access to the mutex, and removes duplicated code.
And make the Base Profiler mutex&lock consistent.
Differential Revision: https://phabricator.services.mozilla.com/D119147
Bug 1714577 meant to exclude tools/profiler/public/GeckoTraceEvent.h from
clang-format, but the trailing comment in .clang-format-ignored broke that.
Bug 1519636 then formatted the file.
This fixes the exclusion in .clang-format-ignore and backs out the
clang-format on tools/profiler/public/GeckoTraceEvent.h.
Differential Revision: https://phabricator.services.mozilla.com/D119297
This moves the adding of the end marker for redirects in nsHttpChannel
to SetupReplacementChannel, so that all redirects are properly caught.
Without that, some requests will show as unfinished in the profiler
frontend.
Some of the redirects are internal and we may be able to flag and ignore
them in the frontend, but that's work for the future.
Because all redirections get a "REDIRECT" end marker, including the
internal redirection to the service worker's intercepted channel, we now
need an additional "START" marker there as well.
All existing profiler tests related to service workers needed to be
updated because there's an extra redirect marker in all these requests,
as well as several pairs of markers that all have the same id.
This also adds a new profiler test for handling the http->https case
that we wouldn't catch before this patch.
Differential Revision: https://phabricator.services.mozilla.com/D118836
This patch adds a new linter that will error when new code mentions any one of
the following strings:
* `CoInitialize`;
* `CoInitializeEx`;
* `OleInitialize`;
* `RoInitialize`;
* `CoUninitialize`;
* `OleUninitialize`; and
* `RoUninitialize`.
Since I don't care about context, and just want to flag code containing these
names, I opted for a `regex` linter.
Yes, the regex does match a few strings beyond the above list (in particular, it
also matches additional strings that end with an `Ex` suffix), but since
functions with those names don't exist anyway (and would be errors in their own
right), I am not concerned about it.
All existing occurrences have been added to the exclusion list, with the
intent of removing most of them over time.
Differential Revision: https://phabricator.services.mozilla.com/D119129
This is similar to what DoMozStackWalkBacktrace does, by looking where the stack walker stopped, and if it can be restarted at a calling C++-to-JIT entry frame.
Note: The code is pretty much a modified copy, but factoring out the common parts would be difficult because of the specific local variables, the different stack-walking functions, and the different register storages.
Also, instead of mentioning the OS (was only Windows), the choice of platform support is now based on the actual Profiler stack walkers that are used.
Differential Revision: https://phabricator.services.mozilla.com/D118109
Callbacks can be registered to be called at specific profiler state changes.
This may be useful to make sure some markers are recorded at the end of the profile time range, if some information would be useful to always have available (and it doesn't fit in meta-information or elsewhere).
Differential Revision: https://phabricator.services.mozilla.com/D118128
Then this will make it possible in the UI to relate the redirected
request with its redirection.
With this patch a debug build of Firefox will crash when a redirection
happens, but the next patch will fix this.
Differential Revision: https://phabricator.services.mozilla.com/D118467
These requests had except blocks to catch all requests exceptions. But because
we weren't calling 'raise_for_status', exceptions were never raised, resulting
in bizarre error tracebacks later on.
Depends on D118356
Differential Revision: https://phabricator.services.mozilla.com/D118357
A failure displaying estimates should never cause the try push to fail, as it
is entirely optional. This adds a blanket except to catch any exception that
was mishandled inside the estimates submodule.
It still displays a traceback as any failures displayed here should still
legitimately be fixed or have smoother error handling.
Differential Revision: https://phabricator.services.mozilla.com/D118356
When a user runs 'mach try --full', we continue computing the target task set
and cache it anyway (since we were already almost there and starting over in
the event they re-run without '--full' is very expensive.
However, when implementing the 'cache_key' function in bug 1714178, I forgot to
recompute the key in this case, causing the contents of 'target_task_set' to
overwrite the 'full_task_set' cache.
This also includes a minor improvement to re-use the 'full_task_set' cache
regardless of 'disable_target_task_filter', as that flag has zero bearing on
the full task graph. This should result in fewer cache misses when using
--full.
Differential Revision: https://phabricator.services.mozilla.com/D118531
This reverses bug 1703410: By default the profiler now changes the timer resolution (normally 64Hz) when the requested sampling interval is lower than 10ms, to allow fast-enough sampling for most uses.
But since this can influence other timers in Firefox, it makes debugging some types of issues more difficult. To help with this, there is now a "No Timer Resolution change" on Windows, which prevents the profiler from changing the timer resolution, at a risk of slowing down sampling in some processes.
Differential Revision: https://phabricator.services.mozilla.com/D117626
Now the test will warn when more properties than expected are received.
This way we won't forget to update the tests when we add more, but we
also assert that some properties are absent in some cases, as expected.
The test has been also changed a lot to pass in verify mode. To make
this easier we disable the HTTP cache.
Differential Revision: https://phabricator.services.mozilla.com/D117679
(Tl;dr: The original author of this patch was axel@mozilla.com (:pike).
This patch has been modified to run in production automation.)
Cross-channel takes all the en-US strings from the shipping train branches
and consolidates them into a single repository. Originally, this ran out of
https://hg.mozilla.org/users/axel_mozilla.com/cross-channel-experimental/ .
The original version was coupled tightly with specific hg internals, making
hg upgrades fragile. Axel wrote
https://bug1659691.bmoattachments.org/attachment.cgi?id=9170636 before
handing off project ownership; this is the original patch to stop replaying
history to simplify the logic.
This patch also automates the previously manual preparation steps, allows
for running both in automation and locally, and adds retries for production
robustness.
Differential Revision: https://phabricator.services.mozilla.com/D116537
This patch forces perfdocs to produce unix line endings rather than os-specific line endings. This fixes an issue where generating the docs on windows causes all the docs to change because of the line endings.
Differential Revision: https://phabricator.services.mozilla.com/D117919
The two 'target_tasks_try_select' target task methods use a hardcoded
"autoland" | "mozilla-central" as the project. This means that you get the set
of tasks for autoland/central even if you e.g, update to beta and pass in
'./mach try fuzzy --parameters project=mozilla-beta'.
This patch ensures we use the proper target tasks method if passing in
non-default parameters. It also fixes the caching to account for this
new project.
Differential Revision: https://phabricator.services.mozilla.com/D117941
- Don't throw when a placeable is enclosed in double straight quotes
- Catch single quotes used as genitive on plural nouns
Differential Revision: https://phabricator.services.mozilla.com/D117898
This allows using the Gecko Profiler without pulling in half of Gecko (nsTArray,
nsString, etc.). This is for use in third party code, that we lightly patch to
register the threads.
Differential Revision: https://phabricator.services.mozilla.com/D116839
Renovate Bot
Mark Banner
Sylvestre Ledru
Mitchell Hentges
Dzmitry Malyshau
Nazım Can Altınova
Benjamin Peterson
Belén Albeza
Gerald Squelart
Julian Descottes
Joel Maher
Marco Castelluccio
Marian-Vasile Laza
Christopher Winter
Andi-Bogdan Postelnicu
criss
Alex Lopez
Julien Wajsberg
Brindusan Cristian
Mike Hommey
André Bargull
Toshihito Kikuchi
Kimberly Sereduck
Butkovits Atila
Markus Stange
Florian Quèze
Emilio Cobos Álvarez
Barret Rennie
Zibi Braniecki
Andrew Osmond
Noemi Erli
Florin Strugariu
Christoph Kerschbaumer
Sandor Molnar
Gijs Kruitbosch
Nika Layzell
Kajal Sah
surajeet310
Tom Ritter
Tooru Fujisawa
Steve Fink
Michael Froman
Aaron Klotz
Gabriele Svelto
Alexis Beingessner
Andrew Halberstadt
Aki Sasaki
Gregory Mierzwinski
Iulian Moraru
Francesco Lodolo (:flod)
Kershaw Chang
Dan Mosedale
Myeongjun Go
championshuttler
Paul Adenot
Tim Giles