Setting MALLOC_XMALLOC enables a runtime toggle that allows to make
allocations abort() on OOM instead of returning NULL. In other words,
it enables a toggle that allows to turn all allocations into infallible
allocations.
The toggle however still defaults to being disabled, which means even
when MALLOC_XMALLOC is defined when building mozjemalloc, there is no
change in behavior, unless a MALLOC_OPTIONS is set.
Even if this were useful to anyone (MALLOC_XMALLOC is only defined on
debug builds, limiting the usefulness), this is something
replace-malloc, in Firefox, is meant to be used for.
So let's remove this feature, and possibly add an equivalent
replace-malloc later if deemed necessary.
--HG--
extra : rebase_source : 1ccc893e9a8e842c3fa90e91f076a528df2f7dfe
It's a Solaris-only optimization that was used as a workaround for some
infinite loop in pages_map (bug 457189). In the meanwhile, the way
pages_map works has changed in such a way the infinite loop can't happen
anymore.
Specifically, the original problem was that pages_map would try to
allocate something larger than a chunk, then deallocate it, and
reallocate at a hinted aligned address near the address of the now
deallocated mapping, hopefully getting an aligned chunk. But Solaris
would ignore the hint and the chunk would never be aligned, causing the
infinite loop.
What the code does now it over-allocate, find an aligned chunk in there,
and deallocate what ends up not being needed. Which leaves no room for
the original infinite loop.
We thus remove the workaround and put Solaris in par with other Unix
platforms.
--HG--
extra : rebase_source : 9ce4509d9c5ac6123cedabf87c5738672af35d1b
In Gecko code, MOZ_RELEASE_ASSERT means assertions that happen on all
types of builds.
In mozjemalloc, RELEASE_ASSERT means assertions that happen when
MOZ_JEMALLOC_HARD_ASSERTS is set, otherwise normal assertions. Which is
confusing. On the other hand, it's very similar to
MOZ_DIAGNOSTIC_ASSERT, and we may just want to use that instead.
Moreover, with release promotion, the check setting
MOZ_JEMALLOC_HARD_ASSERTS means releases (promoted from beta) would end
up with those asserts while they're not meant to, so
MOZ_DIAGNOSTIC_ASSERT is actually closer to the intent. It however means
we'd lose the beta population running those assertions.
--HG--
extra : rebase_source : 606ab47af8d9ee793b13b806acadb9781c99a078
Support for them was only enabled on debug builds, and required an
opt-in through e.g. MALLOC_OPTIONS to actually enable at runtime.
--HG--
extra : rebase_source : 60c27585c2901a73eb790cec124b880c93da6ef7
While it makes sense for a global system allocator, it's not really
interesting for Firefox to respect that. Plus, newer versions of
jemalloc, which are more likely to be used as a global system allocator
use a different format for the options passed through that file.
--HG--
extra : rebase_source : 0f2283cf5660bc437bd097bf48c2b5989fa08011
Those options, complementing the MALLOC_OPTIONS environment variable,
were always empty since the removal of b2g.
--HG--
extra : rebase_source : 0e34cfce0b537ebb8ed3902bd46180dc205cb0e4
Android NDK defines SYS_mmap2 but it expands to a nonexistent symbol.
mmap2 may not be supported in any case in some AArch64 kernels, so we
should just use mmap.
MozReview-Commit-ID: 5Vjuja5fLIL
The source file is renamed too, because the build system doesn't handle
sources changing suffix very well (at least not without a clobber).
The _GNU_SOURCE define is removed because GCC/Clang set it by default in
C++ mode.
--HG--
rename : memory/mozjemalloc/jemalloc.c => memory/mozjemalloc/mozjemalloc.cpp
extra : rebase_source : f57dbb0a66b25e70fe8c724e9250cc0d8b14f1c1
The hack dates back from the originally imported jemalloc code, which
couldn't assume it's built for Firefox. Now, we can assume that, which
means the code is always built with hidden visibility by default,
removing the need for the explicit hidden visibility.
Correspondingly, when building on Solaris with GCC, the default
visibility should also prevent the inlining, making the noinline
attribute redundant. And the Sun Studio path is useless since the
compiler is not supported anymore.
--HG--
extra : rebase_source : dab0ac68af56b1f9432d312665d4ff3df01fb58a
MOZ_JEMALLOC_API makes those symbols exported, but we're going to make
MOZ_JEMALLOC_API include `extern "C"`, which GCC warns about in this
case (can't use extern on a variable that is initialized).
While we could get around this in some way, there is not much use for
those variables being exported altogether: the only reason they are is
to allow an override when linking mozjemalloc into executables, but
doing that in Firefox requires patching the build system or passing some
specific LDFLAGS. People who really need to do that might as well apply
a patch.
They also allow run-time override through LD_PRELOAD, but one might as
well use the MALLOC_OPTIONS environment variable for _malloc_options.
As for _malloc_message, it doesn't seem very useful to override, and
probably noone ever overrode it at runtime.
Note, we may want to remove them in a followup.
--HG--
extra : rebase_source : f2dbe5dbf0bbdb369cd7c6255f624f16b8e37209
Using -Dabort=moz_abort actually makes the build fail in some libstdc++
headers when building as C++.
--HG--
extra : rebase_source : 77828d5c42f231372a8e75f5e3cd6af135d1d5e8
The source file is renamed too, because the build system doesn't handle
sources changing suffix very well (at least not without a clobber).
The _GNU_SOURCE define is removed because GCC/Clang set it by default in
C++ mode.
--HG--
rename : memory/mozjemalloc/jemalloc.c => memory/mozjemalloc/mozjemalloc.cpp
extra : rebase_source : f57dbb0a66b25e70fe8c724e9250cc0d8b14f1c1
The hack dates back from the originally imported jemalloc code, which
couldn't assume it's built for Firefox. Now, we can assume that, which
means the code is always built with hidden visibility by default,
removing the need for the explicit hidden visibility.
Correspondingly, when building on Solaris with GCC, the default
visibility should also prevent the inlining, making the noinline
attribute redundant. And the Sun Studio path is useless since the
compiler is not supported anymore.
--HG--
extra : rebase_source : dab0ac68af56b1f9432d312665d4ff3df01fb58a
MOZ_JEMALLOC_API makes those symbols exported, but we're going to make
MOZ_JEMALLOC_API include `extern "C"`, which GCC warns about in this
case (can't use extern on a variable that is initialized).
While we could get around this in some way, there is not much use for
those variables being exported altogether: the only reason they are is
to allow an override when linking mozjemalloc into executables, but
doing that in Firefox requires patching the build system or passing some
specific LDFLAGS. People who really need to do that might as well apply
a patch.
They also allow run-time override through LD_PRELOAD, but one might as
well use the MALLOC_OPTIONS environment variable for _malloc_options.
As for _malloc_message, it doesn't seem very useful to override, and
probably noone ever overrode it at runtime.
Note, we may want to remove them in a followup.
--HG--
extra : rebase_source : f2dbe5dbf0bbdb369cd7c6255f624f16b8e37209
Using -Dabort=moz_abort actually makes the build fail in some libstdc++
headers when building as C++.
--HG--
extra : rebase_source : 77828d5c42f231372a8e75f5e3cd6af135d1d5e8
It's always unset, and Firefox has the logalloc replace-malloc library
for something similar.
--HG--
extra : rebase_source : cfe66c004df0d6e5db749f01feb9af591e3d1569
MOZ_MEMORY is always defined when building mozjemalloc. Due to the
origin of the code, this was all FreeBSD-specific code, and if we want
to add FreeBSD support, we will probably need to add some of it, but I'd
rather avoid keeping the difference between FreeBSD and other posix
systems if we can.
--HG--
extra : rebase_source : 3afe0136e35e25361e9e1802a9738d82b97e99e5
jemalloc_stats, as well as pre/post-fork hooks are using the `arenas`
list along the `narenas` count to iterate over all arenas setup by
mozjemalloc. Up until previous commit, that was used for automatic
multiple arenas support, which is now removed.
But mozjemalloc still supports running with multiple arenas, in the form
of opted-in, per-thread arenas. After bug 1361258, those arenas weren't
tracked, and now that `arenas` only contains the default arena, we can
now fill it with those thread-local arenas.
Keeping the automatic multiple arenas support, which we don't use and
don't really plan to, would have meant using a separate list for them.
--HG--
extra : rebase_source : f4eb55a65df8cdebff84ca709738f906d0c3c6f5
As per explained 2 commits earlier, we remove the support for multiple
arenas. We however keep the `arenas` list and the `narenas` count to
use it them to track the opted-in per-thread arenas.
--HG--
extra : rebase_source : 6e05cddd3dd385a0cd6a22fb028ab311b0c00678
mozjemalloc had an optimization that shortcuts using mutexes when the
program is single-threaded. But with code evolution, the check whether
the program had multiple threads running was meant to be true all the
time.
In order to simplify the code, we just remove those checks and dead code
they were hiding in some cases.
--HG--
extra : rebase_source : 3c7a256bffef50761f6fcd6ec876ebabfcf3fdae
Mike Hommey
Iris Hsiao
Jim Chen
Carsten "Tomcat" Book