gcc doesn't like something about the initializer that comes with
jemalloc. Since it's vendor code, make this warning not an error
for -Werror purposes.
Sponsored by: Netflix
This brings in a merge from jemalloc 5.3.0. It's almost fully scripted, except:
Three conflicts resolved by hand:
include/jemalloc/internal/test_hooks.h Use the new name
src/extent.c Use the new code
src/jemalloc.c Use the new code since je_realloc has moved
The script is recorded in FREEBSD-upgrade. The old script did svn
commands that were basically a rebase of our changes. This update has a
series of diff reduction changes before this.
Note: I'd planned on fixing the above three conflicts with commits, but
ran out of time when I did this work in January. I got discouraged when
jemalloc was EOL'd and didn't pick this back up. I did the above by hand
to get this into FreeBSD 15.0
This work is a repeat of the work by Minsoo Choo who did all these
changes and created a pull request. Given the importance of jemalloc, I
audited these changes by redoing them in this series of commits (and
with the script that was checked in). I did this to confince myself and
anybody else in doubt that there was no supply chain attack. The diffs
between this series of commits and Minsoo's work are minor (though the
version skew makes adds some noise). Interested parties can independent
audit each step, I hope. I've listed Minsoo as a co-author since without
his pull request to test again, this wouldn't have been possible.
Thanks to brooks@ for help with getting the jemalloc 3 ABI compat
symbols right.
Co-authored-by: Minsoo Choo <minsoochoo0122@proton.me>
Pull Request: https://github.com/freebsd/freebsd-src/pull/1337
Sponsored by: Netflix
Make it easire to update jemalloc by moving the FreeBSD specific files
and the generated files into lib/libc. This allows us to regenerate them
more easily, and emphasizes a bit that we may have to regenerate stuff
from upstream.
This is necessary to also unthin the import from the vendor branch as
well (which will be needed to simplify the imports in the future since
we are trying to use contrib/jemalloc for two different things).
No functional change.
Sponsored by: Netflix
The more generated things that are in contrib/jemalloc tree, the more
chances for interference goes way up. So, move this file into our
lib/libc tree. I didn't add a 'generated file' line / info, but this is
funky enough I don't think we need that. We do add things to the man
page, and that should be tracked in the contrib/jemalloc tree to allow
better importing experience.
Sponsored by: Netflix
and allow to revert it back to 48 with WITHOUT_JEMALLOC_LG_VADDR_WIDE build
option.
Reviewed by: andrew, emaste
Sponsored by: Advanced Micro Devices (AMD)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D46686
Don't provide default linkage for jemalloc 3.0 compatability symbols.
We stopped declaring these interfaces with the introduction of jemalloc
4.0 prior to FreeBSD 11.0. Any code using them would have had to
declare them manually so stop declaring them and export the symbols
directly for compatability. Arguably they should be x86 only as they
were never declared on other Tier-1 architectures.
Reviewed by: imp, kib
Differential Revision: https://reviews.freebsd.org/D46407
This will enable alternative mallocs to be included in the tree and
selected by setting LIBC_MALLOC. As there is only one today (jemalloc)
this option does nothing, but we expect to add other implementations
in the future. This will also reduce diffs to CheriBSD.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D41660
Create a stdlib/malloc to hold the definition of the malloc interface
(e.g., the Symbol.map file) and make jemalloc a subdirectory. This will
make it easier to integrate alternative allocators such as snmalloc
while making it clear that the current jemalloc symbols are the FreeBSD
API/ABI (for better or worse).
Suggested by: jrtc27
Reviewed by: jrtc27, emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D41457
