As of libc++ 14, the functions are defined in the std namespace rather
than std::<something>, which makes them conflict with our wrapping. This
is not a problem on libstdc++ because the functions are defined in the
library itself rather than the headers.
This was the real reason behind the addition of #ifndef __wasm__ ; this
is a more generic fix for the same problem.
Differential Revision: https://phabricator.services.mozilla.com/D177841
Improve the chance that we catch memory errors with PHC by:
* Increasing the number of PHC slots (increased from 64 to 4096 in most
cases).
* Lower the delay for the first PHC allocation, with more slots we can
afford to trap allocations from earlier in Firefox's startup.
These improve the chance PHC has of catching an error by 64x, at the cost of
additional 1MB of allocation metadata (on 4KB page size systems). It
shouldn't impact performance more than having PHC on at all.
This patch was originally developed by Randell Jesup.
Differential Revision: https://phabricator.services.mozilla.com/D161934
This changes replace_malloc_usable_size to allow measuring the size of
ptrs that appear anywhere within an allocation page, not just ptrs to the
start of the allocation pages.
This also modifies a gtest to explicitly check the usable size of some
modified pointers, not just the usable size of the pages where those
pointers are located.
Differential Revision: https://phabricator.services.mozilla.com/D170963
See my comment on here for more context of my investigation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1779257#c9
The saved context is invalid once the function that called `getcontext`
returns. We need to call the `getcontext` while the frame where we called it is
still on the stack. That's why this patch is moving the call to `getcontext` to
parent function by inlining the SyncPopulate content by using a macro instead.
This has to be a macro instead of a function because stack pointer address will
be invalid once the `Registers::SyncPopulate` returns. I tried to change this
method to inline but that didn't help either.
Differential Revision: https://phabricator.services.mozilla.com/D170133
The system calls of releasing a chunk of memory can be costly and should be
done outside the arena lock's critical section so that other threads aren't
blocked waiting for the lock.
Differential Revision: https://phabricator.services.mozilla.com/D166775
Some of the runtime options are compiled-in constants when MOZ_DEBUG is not
defined. But it can be useful to enable these configuration options without
enabling the rest of MOZ_DEBUG (eg assertions). This patch adds a new
preprocessor macro to enable runtime configuration.
Differential Revision: https://phabricator.services.mozilla.com/D165920
Poisoning was hardcoded, but to compare different allocators I wanted to
disable it. This patch lets us control poisoning with the MALLOC_OPTIONS
environment variable.
Differential Revision: https://phabricator.services.mozilla.com/D165919
In bug 1794059 it was noted that the IPC shared-memory allocation code
would like to be able to stall-and-retry as well using the same logic.
While it doesn't use VirtualAlloc, the principle is otherwise the same.
Shuffle the relevant code around so that the stall-and-retry logic is
separate from the allocation, in preparation for exporting it.
Differential Revision: https://phabricator.services.mozilla.com/D164106
In bug 1794059 it was noted that the IPC shared-memory allocation code
would like to be able to stall-and-retry as well using the same logic.
While it doesn't use VirtualAlloc, the principle is otherwise the same.
Shuffle the relevant code around so that the stall-and-retry logic is
separate from the allocation, in preparation for exporting it.
Differential Revision: https://phabricator.services.mozilla.com/D164106
We want to be precise about types used here. Although in practice unsigned
is the same as uint32_t, it's not guaranteed. We want to definitely use
32-bit multiplication as it can be faster than 64-bit.
Differential Revision: https://phabricator.services.mozilla.com/D164889
Rename the `m` and `p` variables to match those used in the Hacker's Delight
book where the algorithm is presented. There were also some inconsistent
names in comments that this fixes.
Differential Revision: https://phabricator.services.mozilla.com/D164887
This structure is more optimal if it is somewhat aligned with the system's
cache line length (which we assume is 64 bytes but that's not always true).
This reduces the number of cache lines required to access one record on
average. On 32-bit systems we can manage 32-bytes, on 64-bit systems we can
manage 48 bytes. We do this by:
* Make mRunSize the number of pages in a run rather than bytes, so that it can
be stored in a single byte and save some space in bin headers.
* Make mNumRuns a uint32_t on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D140036
This code path would choose from several ways about how to divide numbers.
By calculating the inverse of the divisor early we can elude all the
branches along this code path we can make it faster than the previous code
or naive division.
Differential Revision: https://phabricator.services.mozilla.com/D132322
This structure is more optimal if it is somewhat aligned with the system's
cache line length (which we assume is 64 bytes but that's not always true).
This reduces the number of cache lines required to access one record on
average. On 32-bit systems we can manage 32-bytes, on 64-bit systems we can
manage 48 bytes. We do this by:
* Make mRunSize the number of pages in a run rather than bytes, so that it can
be stored in a single byte and save some space in bin headers.
* Make mNumRuns a uint32_t on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D140036
This code path would choose from several ways about how to divide numbers.
By calculating the inverse of the divisor early we can elude all the
branches along this code path we can make it faster than the previous code
or naive division.
Differential Revision: https://phabricator.services.mozilla.com/D132322
It is possible to specify full names for capabilities when using the clang
thread-safety analysis which will be used in error messages. We should use that
form of the attribute rather than the legacy lockable attribute.
Differential Revision: https://phabricator.services.mozilla.com/D160531
The past couple of weeks of crash telemetry indicate that stalling on
OOM in child processes for half as long as in main processes drastically
reduces child process OOM crashes without noticeably increasing
main-process OOM crashes.
Give it a ticket and send it on its way.
Differential Revision: https://phabricator.services.mozilla.com/D158790
Refactor to allow specifying a potentially variable stall-count and
-time, rather than a binary stall/don't-stall cue.
No functional changes; this facility will actually be used in the next
commit.
Differential Revision: https://phabricator.services.mozilla.com/D157139
Sufficient data has been acquired to confirm that all-stall does indeed
increase the chance of a main-process OOM compared to just main-stall.
Revert to all-stall anyway, solely to simplify the next two commits.
Differential Revision: https://phabricator.services.mozilla.com/D157138
A recent patch for bug 965392 (now reverted) may have been causing
additional memory use and OOM-crashes. To confirm this, temporarily(?)
revert all-process stalling on Nightly to the main-process-only version
active between 2022-07-28 and 2022-08-25, to collect a few days' worth of
telemetry.
On Beta and later, there are no functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D157124
It's suspected that this may induce performance regressions. Do it
anyway, just to find out how bad it is. (But only on Nightly, for now.)
For simplicity's sake, this does not include any additional telemetry;
the decision of whether and what any additional telemetry is needed will
be deferred until we have some feedback from what we've already got.
Differential Revision: https://phabricator.services.mozilla.com/D155301
Since mozglue is now aware of Gecko process-types, remove the
configurator for this bug's associated experiment. Instead, use
`GeckoProcessType` directly in mozjemalloc.
This requires a couple of adjustments for non-Firefox uses of
mozjemalloc:
- Since `logalloc-replay` uses mozjemalloc in an odd way, tweak its
`moz.build` to also include `mozglue/misc/ProcessType.cpp`.
- Since `GeckoProcessType` is not available in standalone SpiderMonkey
builds, make the mostly-arbitrarily choice to always stall there.
No functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D155300
On macOS versions prior to 10.15 os_unfair_locks cannot spin in kernel-space
which degrades performance significantly. To obviate for this we spin in
user-space like OSSpinLock does, for the same number of times and invoking
x86-specific pause instructions in-between the locking attempts to avoid
starving a thread that might be running on the same physical core.
Differential Revision: https://phabricator.services.mozilla.com/D154205
Although further experiments and refinements are called for, the effect
of this patch has been overall significantly positive. Let it ride the
trains as-is for Fx 105, rather than blocking on those experiments.
(This patch conflicts with D153784, which will need to be rebased and
moved to a new Bugzilla bug.)
Depends on D153783
Differential Revision: https://phabricator.services.mozilla.com/D154839
Since the plausible timeframe for immediate panicked reversion of the
previous patchset has passed without incident, unpin and clean up the
remaining uses of `sChildProcessType` from nsEmbedFunctions.cpp.
Additionally, get rid of the rump declaration of `..._set_always_stall`
on non-Windows builds.
No functional changes.
(Reference: bug 1682520, D152198.)
Differential Revision: https://phabricator.services.mozilla.com/D153783
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Differential Revision: https://phabricator.services.mozilla.com/D154619
All JSONWriteFuncs are effectively final, this patch enforces that, hopefully
helping the compiler to de-virtualize some calls.
Depends on D154618
Differential Revision: https://phabricator.services.mozilla.com/D154619
Implement a drop-in-replacement wrapper for `VirtualAlloc` which, rather
than returning immediately on failure, instead `::Sleep()`s and retries.
This will cause performance regressions in some (presumed-uncommon)
circumstances; this wrapper is therefore only enabled in Nightly, to
collect data on its efficacy and on the severity of those regressions.
Differential Revision: https://phabricator.services.mozilla.com/D150619
Implement a drop-in-replacement wrapper for `VirtualAlloc` which, rather
than returning immediately on failure, instead `::Sleep()`s and retries.
This will cause performance regressions in some (presumed-uncommon)
circumstances; this wrapper is therefore only enabled in Nightly, to
collect data on its efficacy and on the severity of those regressions.
Differential Revision: https://phabricator.services.mozilla.com/D150619
Add the customary bevy of thread-safety annotations to the Mutex types
in memory/build.
Almost all existing instances of these Mutexes are already marked with
MOZ_UNANNOTATED, but this turns out not to matter: MOZ_UNANNOTATED has
no equivalent under clang's `-Wthread-safety` attributes. There are no
variables declared to be guarded by these mutexes, but they must still
be unlocked and relocked in principled ways -- or, alternatively, only
have unverifiable actions taken in appropriately-annotated code.
The primary offenders here are the `pthread_atfork` hooks; these can't
all be annotated precisely (and couldn't be checked even if they were),
so we simply mark them all as unanalyzable. The only other warning is
from a highly unusual (but already well-commented) bit in PHC.cpp where
we manually release an autolocked mutex before crashing.
Differential Revision: https://phabricator.services.mozilla.com/D150519
Add the customary bevy of thread-safety annotations to the Mutex types
in memory/build.
Almost all existing instances of these Mutexes are already marked with
MOZ_UNANNOTATED, so there's not much else required for this patch. The
sole exception is a highly unusual (but already well-commented) bit in
PHC.cpp where we manually release an autolocked mutex before crashing.
Differential Revision: https://phabricator.services.mozilla.com/D150519
I went through the docs and fixed up a few things. I also removed the other
version that was imported under XPCOM, updated a few obsolete MDN links that
now have updated docs, and deleted some ancient Bonsai links.
Differential Revision: https://phabricator.services.mozilla.com/D150504
macOS unfair locks enforce that a lock can only be released by the thread which locked it.
On macOS 11+ this caused the fork()'d child process to raise a SIGILL signal. Confusingly enough this behavior seems to be different on macOS 10.15 and possibly interacted in odd ways with our exception handler if it was installed before fork()-ing.
Differential Revision: https://phabricator.services.mozilla.com/D148287
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
For a unified it is possible to include FdPrintf.cpp before FdPrintf.h which
creates a compilation warning for FdPrintf's attributes. FdPrintf.cpp
should include FdPrintf.h so that the declaration always precedes the
definition.
Depends on D132913
Differential Revision: https://phabricator.services.mozilla.com/D132914
-Wshadow warnings are not enabled globally, so these -Wno-shadow suppressions have no effect. I had intended to enable -Wshadow globally along with these suppressions in some directories (in bug 1272513), but that was blocked by other issues.
There are too many -Wshadow warnings (now over 2000) to realistically fix them all. We should remove all these unnecessary -Wno-shadow flags cluttering many moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D132289
This MOZ_CRASH() is redundant after calling noreturn function mozalloc_abort. The MOZ_ASSUME_UNREACHABLE_MARKER() annotation makes ARM's "function declared 'noreturn' should not return" warnings go away.
Differential Revision: https://phabricator.services.mozilla.com/D129115
jemalloc_stats takes an array for its second argument. It expects this
array to have enough space for all the bins, previously the maximum was set
as a magic number. To make it dependent on the configured bins this patch
replaces the compile-time constant with a function.
Differential Revision: https://phabricator.services.mozilla.com/D127761
Mike Hommey
Mark Banner
Paul Bone
Noemi Erli
Norisz Fay
Andrew McCreight
serge-sans-paille
Cristian Tuns
Cosmin Sabou
Brad Werth
Olli Pettay
Nazım Can Altınova
Razvan Cojocaru
Ray Kraesig
Marco Castelluccio
Jeff Muizelaar
Otto Länd
Alexandre Lissy
Barret Rennie
Robert Longson
Csoregi Natalia
Nika Layzell
Tom Ritter
Joel Maher
Gabriele Svelto
Gerald Squelart
Iulian Moraru
Fabrice Desré
Andreea Pavel
Butkovits Atila
Tooru Fujisawa
smolnar
Ryan VanderMeulen
Bogdan Szekely
Marian-Vasile Laza
Serge Guelton
Randell Jesup
Zhao Jiazhong
Chris Peterson
Gian-Carlo Pascutto
criss