Particularly _Unwind_Backtrace which seems to be gcc extension.
This is what glibc's backtrace is commonly is using.
Using _Unwind_Backtrace directly is better than glibc's backtrace, since
it doesn't call into dlopen. While glibc does dlopen when it is built as
shared library apparently to avoid link-time dependency on libgcc_s.so
'XOR loop' in profiler unittest wasn't 100% effective because it allowed
compiler to avoid loading and storing to memory.
After marking result variable as volatile, we're now forcing compiler to
read and write memory, slowing this loops down sufficiently. And
profiler_unittest is now passing more consistently.
Closes#628
Particularly, on arm-linux and x86-64-debian-kfreebsd compilation fails
due to lack of support for ifunc. So it is necessary to test at
configure time whether ifunc is supported.
malloc_hook.h includes malloc_hook_c.h as <gperftools/malloc_hook_c.h>.
This requires the compiler to have designated src/gperftools as a
standard include directory (-I), which may not always be the case.
Instead, include it as "malloc_hook_c.h", which will search in the same
directory first. This will always work, regardless of whether it was
designated a standard include directory.
It causes a noticeable performance hit and can sometimes confuse GDB.
Tested with CPUPROFILE_PER_THREAD_TIMERS=1.
Based on an old version by mnissler@google.com.
that it isn't used by the program, as it might still be needed to override the
corresponding symbol in shared libraries (or inline assembler for that matter).
For example, suppose the program uses malloc and free but not calloc and is
statically linked against tcmalloc (built with -flto) and LTO is done. Then
before this patch the calloc alias would be deleted by LTO due to not being
used, but the malloc/free aliases would be kept because they are used by the
program. Suppose the program is dynamically linked with a shared library that
allocates memory using calloc and later frees it by calling free. Then calloc
will use the libc memory allocator, because the calloc alias was deleted, but
free will call into tcmalloc, resulting in a crash.
It was reported that clang on OSX doesn't support alias attribute. Most
likely because of executable format limitations.
New code limits use of alias to gcc-compatible compilers on elf
platforms (various gnu and *bsd systems). Elf format is known to support
aliases.
Some workloads get much slower with too large batch size.
This closes bug #678.
binary_trees benchmark benefits from larger batch size. And I found that
512 is not much slower than huge value that we had.
Under gcc 4.5 or greater we're using ifunc function attribute to resolve
sized delete operator to either plain delete implementation (default) or
to sized delete (if enabled via environment variable
TCMALLOC_ENABLE_SIZED_DELETE).
gcc 5 and clang++-3.7 support sized deallocation from C++14. We are
taking advantage of that by defining sized versions of operator delete.
This is off by default so that if some existing programs that define own
global operator delete without sized variant are not broken by
tcmalloc's sized delete operator.
There is also risk of breaking exiting code that deletes objects using
wrong class (i.e. base class) without having virtual destructors.
gcc is only giving warning for unknown -Wno-XXX flags so test never
fails on gcc even if -Wno-XXX is not supported. By using
-Wunused-result we're able to test if gcc actually supports it.
This fixes issue #703.
Using a single fixed directory would break when tests were being run in
parallel with "make -jN".
Also, the cleanup at the end of the test didn't work because it referred
to the wrong variable.
This also makes them output nicer results. I.e. every benchmark is run 3
times and iteration duration is printed for every run.
While this is still very synthetic and unrepresentave of malloc performance
as a whole, it is exercising more situations in tcmalloc fastpath. So it a
step forward.
Looks like existing "trick" to avoid inlining doesn't really prevent
sufficiently smart compiler from inlining Mallocer function. Which
breaks tests, since test relies Mallocer having it's own separate stack
frame.
Making mallocer_addr variable volatile is seemingly enough to stop that.
We still check number of cpus in the system (in spinlock code), but old
code was built under assumption of "no calls malloc" which is not needed
in tcmalloc. Which caused it to be far more complicated than
necessary (parsing procfs files, ifdefs for different OSes and arch-es).
Also we don't need clock cycle frequency measurement.
So I've removed all complexity of ald code and NumCPUs function and
replaced it with GetSystemCPUsCount which is straightforward and
portable call to sysconf.
Renaming of cpus count function was made so that any further code that
we might port from Google that depends on old semantics of NumCPUs will
be detected at compile time. And has to be inspected for whether it
really needs that semantics.
Spinlock usage of cycle counter is due do tracking of time it's spent
waiting for lock. But this tracking is only useful we actually have
synchronization profiling working, which dont have. Thus I'm dropping
calls to this facility with eye towards further removal of cycle clock
usage.
So that LD_PRELOAD-ing doesn't force loading libpthread.so which may
slow down some single-threaded apps.
tcmalloc already has maybe_threads facility that can detect if
libpthread.so is loaded (via weak symbols) and provide 'simulations' of
some pthread functions that tcmalloc needs.
