This is the first and simplest API for the markers. There will be two more
APIs in the following patches (add_text_marker and add_marker). You can see the
PROFILER_MARKER_UNTYPED macro for the C++ counterpart.
Differential Revision: https://phabricator.services.mozilla.com/D124022
These structs are needed for the marker APIs. We also have the same structs as
the C++ classes. See `mozilla::MarkerTiming` and `mozilla::MarkerOptions`.
Differential Revision: https://phabricator.services.mozilla.com/D124020
Because string contents could be split in two separate chunks, the default ProfilerStringView deserializer needed to concatenate it together in an off-chunk buffer.
But now thanks to ProfileBufferEntryReader::ReadSpans, it is possible to know if the contents are in a single memory area inside one chunk (which should be the vast majority of cases), in which case the ProfilerStringView can just reference it using its internal std::string_view, which saves managing a separate buffer and copying data into it.
However this can only be done safely when the span is correctly aligned for the character type, which may not be the case for char16_t strings that must be even-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D124430
Instead of always having to use `ReadBytes` to copy bytes out of the profile buffer into an external buffer, these functions provide one or two spans (pointer+size) pointing at the area, which can be used to look at the data without copying it, especially in the majority of cases where areas are fully inside one chunk and only need one span to address.
Differential Revision: https://phabricator.services.mozilla.com/D124429
`ProfilerStringView::Data()` would return a pointer to the start of the string, but there may not be a null terminator at the end!
To reduce the likelihood of misuses, that function has now been removed.
Instead, callers must now access the data through `AsSpan` or the `Span` conversion operator (which makes it easy to use with `NS_ConvertUTF16toUTF8` for example).
It was not an issue until now, because deserialized string would always be terminated when copied out of the profile buffer, but a following patch will add optimized code where the non-terminated string inside the buffer will be directly pointed at.
Differential Revision: https://phabricator.services.mozilla.com/D125027
This will allow starting Firefox in the background, and on Windows will allow
closing the last browser window without killing the main process. There is no
plan for actually using this by default in Firefox proper, but it's needed for
some explorations.
There's more to this work that we'll need - this is just the first step. For
instance, we'll need a real way to actually kill firefox on Windows other than
through the task manager (we'll be putting something in the system tray to
allow this.)
The patch wasn't particularly large, so I didn't split out the rename of
MOZ_APP_SILENT_START to MOZ_APP_SILENT_RESTART - let me know if you'd like me
to do that though and I can.
Differential Revision: https://phabricator.services.mozilla.com/D124249
Because string contents could be split in two separate chunks, the default ProfilerStringView deserializer needed to concatenate it together in an off-chunk buffer.
But now thanks to ProfileBufferEntryReader::ReadSpans, it is possible to know if the contents are in a single memory area inside one chunk (which should be the vast majority of cases), in which case the ProfilerStringView can just reference it using its internal std::string_view, which saves managing a separate buffer and copying data into it.
However this can only be done safely when the span is correctly aligned for the character type, which may not be the case for char16_t strings that must be even-aligned.
Differential Revision: https://phabricator.services.mozilla.com/D124430
Instead of always having to use `ReadBytes` to copy bytes out of the profile buffer into an external buffer, these functions provide one or two spans (pointer+size) pointing at the area, which can be used to look at the data without copying it, especially in the majority of cases where areas are fully inside one chunk and only need one span to address.
Differential Revision: https://phabricator.services.mozilla.com/D124429
Because string contents could be split in two separate chunks, the default ProfilerStringView deserializer needed to concatenate it together in an off-chunk buffer.
But now thanks to ProfileBufferEntryReader::ReadSpans, it is possible to know if the contents are in a single memory area inside one chunk (which should be the vast majority of cases), in which case the ProfilerStringView can just reference it using its internal std::string_view, which saves managing a separate buffer and copying data into it.
Differential Revision: https://phabricator.services.mozilla.com/D124430
Instead of always having to use `ReadBytes` to copy bytes out of the profile buffer into an external buffer, these functions provide one or two spans (pointer+size) pointing at the area, which can be used to look at the data without copying it, especially in the majority of cases where areas are fully inside one chunk and only need one span to address.
Differential Revision: https://phabricator.services.mozilla.com/D124429
All the code that uses it was conditioned on ShouldUseProgressivePaint(),
which was changed to always return false in the previous commit.
This also fixes a racy access to this static variable.
Depends on D123712
Differential Revision: https://phabricator.services.mozilla.com/D123713
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
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
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
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
PROFILER_RUNTIME_STATS was broken recently. It's only used during development (mostly to benchmark new code), so it's not critical and no tests are needed.
Differential Revision: https://phabricator.services.mozilla.com/D122677
Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.
Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D122384
Per the discussion on governance, the new DLL services module will live in
`toolkit/xre/dllservices`.
Mozglue code will live in `toolkit/xre/dllservices/mozglue` and will be linked
in with `mozglue.dll`.
Differential Revision: https://phabricator.services.mozilla.com/D122384
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
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 call appears in the top frames of 2 different stacks (Bug 1723351 and Bug 1723142) so from my understanding it will suppress both test fails. I included both bug numbers for reference.
Differential Revision: https://phabricator.services.mozilla.com/D121546
Previously ProfilingCategoryList.h was a central place for profiling
categories. But with this patch, profiling_categories.yaml becomes the
canonical place for it and the macro header file is being generated
automatically. This is needed to make the profiling categories in sync with
Rust and C++.
Differential Revision: https://phabricator.services.mozilla.com/D120791
We had crashes in `PEHeaders::FindResourceLeaf` where `idDir` was nullptr. This can
happen when the resource table is modified by a third-party application and an entry
in the table points to somewhere outside the executable.
Differential Revision: https://phabricator.services.mozilla.com/D121093
Sanitizers try to intercept __tls_get_addr to find DTLS blocks. In some
cases, they fail miserably with a crash. And in the cases they don't
crash, they don't seem to actually work properly anyways.
This affects both build time when running host programs compiled with
sanitizer flags (this only actually affects rust build
scripts/procedural macros on non-cross builds, not C/C++ host programs),
and execution time, e.g. when running tests.
Differential Revision: https://phabricator.services.mozilla.com/D120574
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
Originally these includes were wrapped in an ACCESSIBILITY define because the
bug that manifested only affected screen readers. However, theoretically
speaking other things *could* cause us to initialize COM early and run into
troubles, so this is not *strictly* an a11y issue from that perspective. It
wasn't wrapped around ACCESSIBILITY defines inside PreXULSkeletonUI.cpp for
this reason, but there was still lingering inconsistency inside the moz.build
file. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D119541
It looks like this suppression was removed downstream, but StartupCache's behavior still exists so it most likely stopped causing failures because of some other suppression interacting with it. I decided the best course of action was to put it back as a perma suppression in gecko in case we run into it again.
Differential Revision: https://phabricator.services.mozilla.com/D119783
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
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
This implements Jamie's suggested fixes for a screenreader issue when the
skeleton UI is enabled. Most of the work here is just pulling out pieces from the
files we needed to include in mozglue so that any references to, say, nsString
or other pieces from libxul either no longer exist or are only included when
building libxul. In a few cases this meant creating whole files to house single
functions, which isn't so pretty, but it was the best I could come up with to
get the job done.
Differential Revision: https://phabricator.services.mozilla.com/D117663
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
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
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
When a module is loaded with `LOAD_LIBRARY_AS_IMAGE_RESOURCE`, the mapped region
is `MEM_IMAGE`, but it's not executable. We don't have to check the blocklist
in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D117573
BP may contain the stack address where the caller's BP was pushed after the function call, in which case it's possible to carefully unwind from it.
This can get past JIT code, so there is no need to give up in this case.
mozglue was already linked with ntdll, but now that we use it directly (for `NtQueryInformationThread`), ntdll needed to be added to some other users of MozStackWalkThread.
Differential Revision: https://phabricator.services.mozilla.com/D115962
