glibc marks various allocation functions as `throw()`. This addition
hasn't been a problem until we tried to enable C++17, where clang
started complaining that we were redeclaring functions with mismatched
exception specifications. Peculiarly, glibc declares virtually
everything we redeclare as `throw()`, but clang only complains about the
mismatches for a particular subset of functions.
The approach taken in this patch is to add another potentially defined
macro to malloc_decls.h, `NOTHROW_MALLOC_DECL`. This macro works
exactly like `MALLOC_DECL`, except that clients can define
`NOTHROW_MALLOC_DECL` to add appropriate `throw()` specifiers when
declaring functions at global scope, and thereby avoid mismatched
exception specifications.
Differential Revision: https://phabricator.services.mozilla.com/D44045
--HG--
extra : moz-landing-system : lando
- On Android, we were already doing it, but using fallible allocations.
- On *nix, it probably doesn't make a difference, but can't hurt. For
most things in Gecko, operator new/delete are inlined and thus
replaced by direct calls to the underlying allocator functions
(moz_xmalloc, malloc, etc.). This may have a benefit for some third
party libraries that would otherwise go through libstdc++'s to
eventually end up back into our allocator via the zone allocator
on macOS and via the exported symbols on others.
- On Windows, because of how some CRT static libraries are, a non-inlined
operator new (thanks to some disabled STL wrapping) would end up linked
against the system malloc, causing problems.
Overall, this can only be better. This also reduces the number of places
where we define those functions.
And on Android, this means operator new within mozglue becomes infallible,
which is more consistent with everything else.
Differential Revision: https://phabricator.services.mozilla.com/D36166
--HG--
extra : moz-landing-system : lando
Bug 1147248 added the workaround for GCC 4.9, but from an attempt with
GCC 6, it seems unnecessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D36165
--HG--
extra : moz-landing-system : lando
- On Android, we were already doing it, but using fallible allocations.
- On *nix, it probably doesn't make a difference, but can't hurt. For
most things in Gecko, operator new/delete are inlined and thus
replaced by direct calls to the underlying allocator functions
(moz_xmalloc, malloc, etc.). This may have a benefit for some third
party libraries that would otherwise go through libstdc++'s to
eventually end up back into our allocator via the zone allocator
on macOS and via the exported symbols on others.
- On Windows, because of how some CRT static libraries are, a non-inlined
operator new (thanks to some disabled STL wrapping) would end up linked
against the system malloc, causing problems.
Overall, this can only be better. This also reduces the number of places
where we define those functions.
And on Android, this means operator new within mozglue becomes infallible,
which is more consistent with everything else.
Differential Revision: https://phabricator.services.mozilla.com/D36166
--HG--
extra : moz-landing-system : lando
Bug 1147248 added the workaround for GCC 4.9, but from an attempt with
GCC 6, it seems unnecessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D36165
--HG--
extra : moz-landing-system : lando
The current situation is suboptimal, where we have the same goop
repeated in multiple files, and where things kinda sorta work out fine
thanks to the linker for files that would have been forbidden, except
when the linker doesn't do its job, which apparently happen on
mingwclang builds.
This change only really covers C++ code using operator new/delete, and
not things that would be using malloc/free, because it's easier.
malloc/free is left for a followup.
Differential Revision: https://phabricator.services.mozilla.com/D32119
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
The std::nothrow variant of operator new is effectively a fallible
operator new. It is used in third party code.
The duplication with our own fallible operator new is unfortunate, and
we can reduce it by making one an alias of the other.
We keep the fallible library as a dummy on Android because bug 1423802
induces some linking problems.
--HG--
extra : rebase_source : d7b915aaafde40057e87b7ad4bbd82d348e4f12d
Bug 1163171 removed support for building for android with GCC, and we
don't need to use throw() anymore. We can use the same code as for other
non-Windows platforms.
--HG--
extra : rebase_source : 9c2c2179a6d214096619ff0ae1d1a42912beda79
MOZ_ALWAYS_INLINE_EVEN_DEBUG is always defined through
mozilla/Attributes.h, so the fallbacks are never used in practice. They
are just there from the old days when mozalloc.h didn't use
mozilla/Attributes.h.
--HG--
extra : rebase_source : 0d55068ab5fcec3f4bcafecd8c3ce371597f8cfe
They are both infallible wrappers of posix_memalign and valloc.
There is also moz_xmemalign, which wraps memalign, which is mostly
always available as of bug 1402647.
None of them are actually used, but it's still desirable to at least
have one infallible variant, so keep moz_xmemalign and remove the other
two.
While here, we actually make both memalign and moz_xmemalign always
available.
--HG--
extra : rebase_source : 1c3ca4b3e3310543145f3181dfa4e764be1d6ff8
When this was added, the xpcom glue was still a thing, and there was a
distinction between things that would build with mozalloc available and
others. There is no such distinction anymore. Anything that has access
to xpcom has access to infallible allocator functions.
--HG--
extra : rebase_source : 04bce114e940c53709275d0354ea7240df4a051e
They are both infallible wrappers of posix_memalign and valloc.
There is also moz_xmemalign, which wraps memalign, which is always
available as of bug 1402647.
None of them are actually used, but it's still desirable to at least
have one infallible variant, so keep moz_xmemalign and remove the other
two.
While here, we actually make moz_xmemalign always available, since
memalign is always available.
--HG--
extra : rebase_source : 17300bc03a715e5d36b4b687f22050622c1c70c8
We currently turn off the C++14 sized-deallocation facility on MSVC, and
we'd like to ensure we do the same thing for clang and gcc. To do so,
we add new functionality to moz.configure for checking and adding
compilation flags, similar to the facility for checking and adding
warning flags. The newly added facility is then used to add
-fno-sized-deallocation to the compilation flags, when the option is
supported.
Once we do this, we can't define the sized deallocation functions in
mozalloc.h; the compiler will complain that we are using
-fno-sized-deallocation, yet defining these special functions that we'll
never use. These functions were added for MinGW, where we needed to
compile with C++14 ahead of other platforms to be compatible with MSVC
headers. But they're no longer necessary, though they would be if we
removed -fno-sized-deallocation; the compiler will complain if we do
that and we'll add them back at that point.
jemalloc_ptr_info() gives info about any pointer, such as whether it's within a
live or free allocation, and if so, info about that allocation. It's useful for
debugging.
moz_malloc_enclosing_size_of() uses jemalloc_ptr_info() to measure the size of
an allocation from an interior pointer. It's useful for memory reporting,
especially for Rust code.
--HG--
extra : rebase_source : caa19cccf8c2d1f79cf004fe6a408775de5a7b22
Bug 1207519 added maybe_pod_* methods to the allocation policy
classes, but did not add them to InfallibleAllocPolicy.
I think the idea of these methods is that the callers are explicitly
opting into fallible behavior, so they will deal with any errors that
occur. For instance, in js::HashTable, this is used to try to shrink
the hash table when there are a lot of unused entries. If the shrink
fails, it just continues to use the existing block of memory.
However, having fallible methods in a supposedly infallible class is
weird, so for now, just use the infallible version.
MozReview-Commit-ID: 97D66Z4oLfl
--HG--
extra : rebase_source : 9a3e0b50a5602a8e4772da88c16e1715c25da7df
Code that uses InfallibleAllocPolicy presumably wants for operations
to always succeed. However, Vector and HashTable can end up detecting
that growing the data structure will fail due to integer overflow, and
then will call reportAllocOverflow() and fail. I think these cases
should crash.
In addition, pod_malloc and pod_realloc should crash rather than
returning NULL when they detect overflow.
This calls mozalloc_abort rather than MOZ_CRASH directly to avoid
circular #includes, because Assertions.h includes nsTraceRefcnt.h
which includes nscore.h which includes mozalloc.h.
MozReview-Commit-ID: 1g99BXLceQI
--HG--
extra : rebase_source : 927d842588c1f85a50a7a1c50a5546d5f688555f
Since the introduction of the STL wrappers, they have included
mozalloc.h, and multiple times, we've hit header reentrancy problems,
and worked around them as best as we could.
Taking a step back, all mozalloc.h does is:
- declare moz_* allocator functions.
- define inline implementations of various operator new/delete variants.
The first only requires the functions to be declared before they are used,
so mozalloc.h only needs to be included before anything that would use
those functions.
The second doesn't actually require a specific order, as long as the
declaration for those functions comes before their use, and they are
either declared in <new> or implicitly by the C++ compiler.
So all in all, it doesn't matter that mozalloc.h is included before the
wrapped STL headers. What matters is that it's included when STL headers
are included. So arrange things such that mozalloc.h is included after
the first wrapped STL header is fully preprocessed (and all its includes
have been included).
It's an annotation that is used a lot, and should be used even more, so a
shorter name is better.
MozReview-Commit-ID: 1VS4Dney4WX
--HG--
extra : rebase_source : b26919c1b0fcb32e5339adeef5be5becae6032cf
We need to use _impl variants within mozalloc.h when they are defined because
of how mozglue.dll is linked on Windows, where using malloc/free would use
the symbols from the MSVCRT instead of ours.
Nathan Froyd
Mike Hommey
Andreea Pavel
Ehsan Akhgari
Tooru Fujisawa
Benjamin Bouvier
Sylvestre Ledru
Nicholas Nethercote
Brian Hackett
Masatoshi Kimura
Carl Corcoran
Gurzau Raul
Ryan VanderMeulen
Narcis Beleuzu
Tom Ritter
Sebastian Hengst
Botond Ballo
Andrew McCreight
Bill McCloskey
Jim Blandy
ISHIKAWA, Chiaki