This feature is added as "recommended", and added to every presets. This will
allow us to disable it if we really want to.
If the "native allocations" feature is enabled, we still force the installation
of the memory hooks even if we don't have this feature to not break the native
allocations feature.
Differential Revision: https://phabricator.services.mozilla.com/D206789
This feature is added as "recommended", and added to every presets. This will
allow us to disable it if we really want to.
If the "native allocations" feature is enabled, we still force the installation
of the memory hooks even if we don't have this feature to not break the native
allocations feature.
Differential Revision: https://phabricator.services.mozilla.com/D206789
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
The global allocator we define for Rust code directs all Rust
allocations to the malloc family of functions. Practically speaking,
it's a no-op on Unix systems (the default global allocator would
do the same thing except for tiny details about alignment on some
platforms), but it makes a big difference on Windows, where the Rust
default global allocator uses the HeapAlloc family of functions.
Well, in practice, it doesn't make a huge difference, because we wrap
those functions to fall back to the malloc family of functions. But
it does make a difference in how allocations with large alignment are
handled (because it does its own alignment on top of HeapAlloc).
We're about to stop wrapping the HeapAlloc family of functions, because
it's causing other problems with memory that might have been
HeapAlloc'ated from system libraries, which a wrapped HeapFree can't
handle without overhead.
But, we're only currently defining the Rust global allocator when
mozjemalloc is enabled, meaning removing the wrapping gets us back to
Rust using HeapAlloc/HeapFree on those builds. Unfortunately, that
exchanges of ownership between C/C++ and Rust can lead to allocator
mismatch (and subsequent heap corruption).
One specific case where this causes problems is ASan builds, which
disable mozjemalloc specifically to enable the ASan allocator.
So we need to always define a Rust global allocator that uses the malloc
family of functions, whether or not mozjemalloc is enabled.
Unfortunately, the current code also relies on _aligned_malloc being
redirected to mozjemalloc, so we also need to adjust it to call
_aligned_free to free the corresponding memory on builds where
mozjemalloc is not enabled.
Differential Revision: https://phabricator.services.mozilla.com/D205787
This allows for individual Marker Types to specify that they wish to have the names passed in profiler_add_marker stored as a field in ETW. This also converts simple marker types to use this in order to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D203983
This allows for individual Marker Types to specify that they wish to have the names passed in profiler_add_marker stored as a field in ETW. This also converts simple marker types to use this in order to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D203983
This commit modifies ProfilingFrameIter to be able to report which tier of
wasm execution a function is in, then uses that in the profiler to report
more fine-grained categories for wasm code.
Differential Revision: https://phabricator.services.mozilla.com/D201020
This patch makes several fundamental changes to the logic we use to inform
the main process whenever the WER runtime exception module intercepts a child
process crash:
* We no longer read the process type or any other data from the child process;
the process type is passed as the runtime exception module's context
* We no longer read the address of the memory area used to communicate with the
main process from the child process arguments. Instead we allocate memory
directly into the main process and store the required information there
* We don't read anything from the main process either, the pointer to the
function used to notify the main process is now found by looking out its
dedicated section in the parent process' xul.dll mapping
* We no longer read the OOM crash annotation from a child process, this
functionality will be restored by making the module use the mozannotation
crates to fetch all the annotations
Differential Revision: https://phabricator.services.mozilla.com/D201589
On Linux and Android, both jitdump and the marker file will keep using
`CLOCK_MONOTONIC` nanoseconds, as before.
On macOS, both jitdump and the marker file will now be using
`TimeStamp::RawMachAbsoluteTimeNanoseconds()` , i.e. "nanoseconds since
mach_absolute_time origin".
This value has the advantage that it is also relatively easy to obtain
in other browser engines, because their internal timestamp value is stored
in milliseconds or nanoseconds rather than in `mach_absolute_time` ticks.
In the past, on macOS, Firefox was using `CLOCK_MONOTONIC` nanoseconds for
jitdump and `TimeStamp::RawMachAbsoluteTimeValue()` for the marker file.
This inconsistency is now fixed.
I will update samply to change how it treats jitdump timestamps on macOS.
There are no other consumers of jitdump files on macOS that I know of.
On Windows, we will keep using raw QPC values for the marker file - this
matches what's in the ETW events. Jitdump on Windows is mostly unused but
I'm updating it to match.
Furthermore, this fixes the order in mozglue/misc/moz.build to make sure
we always use the TimeStamp_darwin implementation on Darwin (and not just
due to a broken configure check, see bug 1681445), and it fixes the #ifdef
in TimeStamp.h to match the Darwin check.
Differential Revision: https://phabricator.services.mozilla.com/D199592
This patch defines shared-libraries.h header file all the time even when the
MOZ_GECKO_PROFILER is not defined. `SharedLibraryInfo` class now has
stubbed-out implementation-specific methods that are defined in platform
specific cpp files. This allows us to always define the header file which
will let us remove a lot of ifdefs in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D199361
We used to rely on our linker being able to decompress zlib streams
directly to memory, but that hasn't been the case for very long.
Differential Revision: https://phabricator.services.mozilla.com/D198912
We used to rely on our linker extracting the libraries to disk before
loading them in memory. This hasn't been the case since bug 1486524.
Differential Revision: https://phabricator.services.mozilla.com/D198911
There is no need to build Zip.cpp anymore when the linker is not
enabled, because nsGeckoUtils.cpp doesn't actually use it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D198349
