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
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
