- Some small automake changes. Add libc++ for AIX instead of libstdc++
- Add the interface changes for AIX:User-defined malloc replacement
- Add code to avoid use of pthreads library prior to its initialization
- Some small changes to the unittest case
- Update INSTALL for AIX
[alkondratenko@gmail.com]: lower-case/de-trailing-dot for commit subject line
[alkondratenko@gmail.com]: rebase
[alkondratenko@gmail.com]: amputate unused AM_CONDITIONAL for AIX
[alkondratenko@gmail.com]: explicitly mention libc_override_aix.h in Makefile.am
We used to explicitly link to libstdc++, libm and even libpthread, but
this should be handled by libtool since those are dependencies of
libtcmalloc_minimal. What also helps is we now build everything with
C++ compiler, not C. So libstdc++ or (libc++) dependency doesn't need
to be added at all, even if libtool for some reason fails to handle
it.
This fixes github issue #1323.
When populating span with linked list of objects ptr + size <= limit
condition could overflow before comparing to limit. So fixed code
carefully tests limit. We also produce version with
__builtin_add_overflow since this is semi-hot loop and we want it to
be fast.
This fixes issue #1371
From time to time things file inside tcmalloc guts where calling to
malloc is not safe. Regular strerror does locale bits, so will
occasionally open files/malloc/etc. We avoid this by using our own
"safe" variant that hardcodes names of all POSIX errno constants.
This patch adds an arm64 implementation of the SpinlockPause() function
allowing the core to adaptively spin to acquire the lock and improving
performance in multi-threaded environments where the locks can be contended.
From experience with other projects, we've found a single isb is the closest
corollary to the rep; nop timing or x86.
Overall, across thirty runs, the binary_trees_shared benchmark improves 6% in
average, median, and P90 runtime with this change.
We had plenty of old and mostly no more correct i386 cruft. Now that
generic_fp backtracer covers i386 just fine, we can drop explicit x86
backtracer.
With that we refactored and simplified stacktrace.cc mostly around
picking default implementation, but also adding few more minor
cleanups.
The idea is -momit-leaf-frame-pointer gives us performance pretty much
same as fully omitting frame pointers. And having frame pointers
elsewhere allows us to support cases when user's code is built with
frame pointers. We also pass all tests with
TCMALLOC_STACKTRACE_METHOD=generic_fp (not just libunwind or libgcc).
Previously we allowed test programs to be linked at the same time as
weakening is performed, rewriting the .a archives. So lets be more
explicit. We weaken after all-am (which "runs" everything including
libraries and programs), but before all target.
It is kinda minor feature, and apparently we never had it working. But
is a nice to have. Allows our users to override malloc/free/etc while
still being able to link to us (for tc_malloc for example). With
broken weakening we had this use-case broken for static library
case. And it should now work.
somehow VerifyIdentical tests fail for some formatting details. But
since it tests --raw feature of our deprecated perl pprof
implementation, which we don't intend supporting anyways, we drop this
test.
There is some details about how wc -l returns stuff and how zsh uses
it to compare to 3. So we now explicitly strip whitespace and it
works.
OSX has really screwed performance for it's memory allocator due to
their malloc zones stuff. We and our competitors hook into that
facility instead directly overriding allocation functions. Which has
massive performance overhead. This is, apparently, so that malloc is
same as allocating from default zone.
As a result, osx'es C++ operator new/delete performance is even worse.
Because we call operator new, it calls malloc, which calls
malloc_zone_malloc, which calls more stuff and eventually tc_malloc.
Thankfully, for C++ API there is no need for such "integration"
between 'stock' memory allocator and malloc zones stuff. So we can
hook those APIs directly. This speeds up malloc_bench numbers on OSX
about 3x.
This change also unbreaks couple tests (e.g. heap profiler unittest)
which depend on MallocHook_GetCallerStackTrace to return precisely
stack trace up to memory allocator call.
Performance-wise, OSX still lacks good TLS and there is still one jump
indirection even for operator new/delete API due to lack support of
aliases. So Linux or BSD, or even windows would still be significantly
faster on malloc performance on same hardware.
OSX's malloc zones facility is calling 'usable size' before each (!)
free and uses size to choose between our allocator and something
else. And returning 0 breaks this choice. Which happens if we got
0-sized malloc request, which our tests exercise couple times. So we
don't let debug allocator on OSX to have 0 sized chunks. This unbreaks
debug allocation tests on OSX.
On OSX we hook into "system's" malloc through this zones facility, so
we need to place those those interface functions into google_malloc
section. This largely unbreaks MallocHook_GetCallerStackTrace on OSX.
For some reason clang shipped with osx miscompiles LowLevelAlloc when
it tries to place Alloc methods into malloc_hooks section. But since
we don't really need that placement on OSX, we can simply drop that
section placement.
In most practical terms, this expands "official" heap leak checker
support to Linux/arm64 and Linux/riscv (mips-en and legacy arm are
likely to work & pass tests too now).
The code is now explicitly Linux-only, without trying to pretend
otherwise. Main goal of this change is to finally amputate
linux_syscall_support.h, which we historically had trouble maintaining
well. Biggest challenge was around thread listing facility which uses
clone (ptrace explicitly fails between threads) and that causes
difficulties around parent and child tasks sharing
errno. linux_syscall_support stuff had special feature to "redirect"
errno accesses. But it caused us for more trouble. We switched to
regular syscalls, and errno stamping avoidance is now simply via
careful programming.
A number of other cleanups is made (such us thread finding codes in
procfs which clearly was built for some ages old and odd kernels).
sem_post/sem_wait synchronization was previously potentially prone to
deadlock (if parent died at bad time). We now use pipe pair for this
synchronization and it is fully robust.
I.e. all recent compilers (both gcc and clang) optimize out delete(new
int) sequence to nothing. We call to tc_new and tc_delete directly to
suppress this optimization.
First, ml64 (amd64 version of masm) doesn't support /coff. Second, it
also doesn't support (nor use) .model directive.
Sadly, asm is inherently amd64-only, so this entire test won't build
in i386 configuration.
This makes our code one step closer to killing unportable custom
atomics implementation. I did manually inspect generated code that
fast-path is identical and slow path's changes of generated code are
cosmetic.
