Adapted from
4e2e3dd9cf
and
d9f7b2a430
As per the latter commit, it would seem unlocking, in fork() child
processes, mutexes that were locked in the parent process is not really
well supported on OSX 10.12. The addition of the zone_reinit_lock
function in 10.12 supports this idea.
--HG--
extra : rebase_source : b3b58558cc195d63200078085c7e9b6c9b8d83ff
We have been using a different zone allocator between mozjemalloc and
replace-malloc for a long time. Jemalloc 4 uses the same as
replace-malloc, albeit as part of the jemalloc upstream code base.
We've been bitten many times in the past with Apple changes breaking the
zone allocator, and each time we've had to make changes to the three
instances, although two of them are similar and the changes there are
straightforward.
It also turns out that the way the mozjemalloc zone allocator is set up,
when a new version of OSX appears with a new version of the system zone
allocator, Firefox ends up using the system allocator, because the zone
allocator version is not supported.
So, we use the same zone allocator for both replace-malloc and
mozjemalloc, making everything on par with jemalloc 4.
--HG--
extra : rebase_source : 9c0e245b5f82bb71294370d607e690c05cc89fbc
Somehow, we never called those hooks when replace-malloc is enabled. I'd
expect this to cause random deadlocks when forking, and I'm surprised
this hasn't surfaced. Maybe it actually causes some intermittent oranges
on automation, who knows.
This also brings consistency with what is done for jemalloc 4, and with
the mozjemalloc implementation, too, that we're going to replace with
this one in a subsequent changeset.
--HG--
extra : rebase_source : 059567d17f928098db8367e9081b631ced351110
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Bug 691003 made the minimum allocation size word sized for Linux and OS X, we
now need to do a similar change on Windows as well. For Windows the requirement
is 8-bytes on 32-bit and 16-bytes on 64-bit.
Bug 691003 made the minimum allocation size word sized for Linux and OS X, we
now need to do a similar change on Windows as well. For Windows the requirement
is 8-bytes on 32-bit and 16-bytes on 64-bit.
This reduces memory usage by up to 3 MiB per process.
MozReview-Commit-ID: Gfs9PIJM4br
--HG--
extra : rebase_source : 69ac5acf7f7f0c802a047f5bf72838e5c4d1f123
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
Now that we have moz.build, we can be guaranteed that any flags we add
in moz.build will be added after everything else has been setup. So any
uses of MODULE_OPTIMIZE_FLAGS can be moved to moz.build's
CFLAGS/CXXFLAGS without any unusual repercussions. We do have to verify
that MOZ_OPTIMIZE is in effect, though.
The reason for --disable-optimize is to make debugging easier, but not many
people actually need a high level of debuggability of the allocator itself.
This works around the issue that the Android NDK's definition of ffs is
broken when compiling without optimization, while avoiding to add yet another
configure test.
