- Add auto-detection of std::align_val_t presence to configure scripts. This
indicates that the compiler supports C++17 operator new/delete overloads
for overaligned types.
- Add auto-detection of -faligned-new compiler option that appeared in gcc 7.
The option allows the compiler to generate calls to the new operators. It is
needed for tests.
- Added overrides for the new operators. The overrides are enabled if the
support for std::align_val_t has been detected. The implementation is mostly
based on the infrastructure used by memalign, which had to be extended to
support being used by C++ operators in addition to C functions. In particular,
the debug version of the library has to distinguish memory allocated by
memalign from that by operator new. The current implementation of sized
overaligned delete operators do not make use of the supplied size argument
except for the debug allocator because it is difficult to calculate the exact
allocation size that was used to allocate memory with alignment. This can be
done in the future.
- Removed forward declaration of std::nothrow_t. This was not portable as
the standard library is not required to provide nothrow_t directly in
namespace std (it could use e.g. an inline namespace within std). The <new>
header needs to be included for std::align_val_t anyway.
- Fixed operator delete[] implementation in libc_override_redefine.h.
- Moved TC_ALIAS definition to the beginning of the file in tcmalloc.cc so that
the macro is defined before its first use in nallocx.
- Added tests to verify the added operators.
[alkondratenko@gmail.com: fixed couple minor warnings, and some
whitespace change]
[alkondratenko@gmail.com: removed addition of TC_ALIAS in debug allocator]
Signed-off-by: Aliaksey Kandratsenka <alkondratenko@gmail.com>
Without this patch, any user program that enables LeakSanitizer will
see a leak from tcmalloc. Add a weak hook to __lsan_ignore_object,
so that if LeakSanitizer is enabled, the allocation can be ignored.
It looks like, in past it could produce better code. But since
unwinding is totally different since almost forever now, there is no
perfomance benefit of it anymore.
I.e. because otherwise, when --enable-minimal is given, we're building
empty libtcmalloc.la and linking it to malloc_bench_shared_full. Which
has no effect at all and actually breaks builds on OSX.
Should fix issue #869.
nallocx is extension introduced by jemalloc. It returns effective size
of allocaiton without allocating anything.
We also support MALLOCX_LG_ALIGN flag. But all other jemalloc
flags (which at the moment do nothing for nallocx anyways) are
silently ignored, since there is no sensible way to return errors in
this API.
This was originally contributed by Dmitry Vyukov with input from
Andrew Hunter. But due to significant divergence of Google-internal
and free-software forks of tcmalloc, significant massaging was done by
me. So all bugs are mine.
Emergency malloc is enabled for cases when backtrace capturing needs to
call malloc. In this case, we enable emergency malloc just prior to
calling such code and disable it after it is done.
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
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.
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.
While this is not good representation of real-world production malloc
behavior, it is representative of length (instruction-wise and well as
cycle-wise) of fast-path. So this is better than nothing.
Default mode of operation of cpu profiler uses itimer and
SIGPROF. This timer is by definition per-process and no spec defines
which thread is going to receive SIGPROF. And it provides correct
profiles only if we assume that probability of picking threads will be
proportional to cpu time spent by threads.
It is easy to see, that recent Linux (at least on common SMP hardware)
doesn't satisfy that assumption. Quite big skews of SIGPROF ticks
between threads is visible. I.e. I could see as big as 70%/20%
division instead of 50%/50% for pair of cpu-hog threads. (And I do see
it become 50/50 with new mode)
Fortunately POSIX provides mechanism to track per-thread cpu time via
posix timers facility. And even more fortunately, Linux also provides
mechanism to deliver timer ticks to specific threads.
Interestingly, it looks like FreeBSD also has very similar facility
and seems to suffer from same skew. But due to difference in a way
how threads are identified, I haven't bothered to try to support this
mode on FreeBSD.
This commit implements new profiling mode where every thread creates
posix timer which tracks thread's cpu time. Threads also also set up
signal delivery to itself on overflows of that timer.
This new mode requires every thread to be registered in cpu
profiler. Existing ProfilerRegisterThread function is used for that.
Because registering threads requires application support (or suitable
LD_PRELOAD-able wrapper for thread creation API), new mode is off by
default. And it has to be manually activated by setting environment
variable CPUPROFILE_PER_THREAD_TIMERS.
New mode also requires librt symbols to be available. Which we do not
link to due to librt's dependency on libpthread. Which we avoid due
to perf impact of bringing in libpthread to otherwise single-threaded
programs. So it has to be either already loaded by profiling program
or LD_PRELOAD-ed.
Because clang doesn't understand -fno-builtin-malloc and friends. And
otherwise new/delete pairs get optimized away causing our tests that
expect hooks to be called to fail.
Somehow it's c++ headers (like string) define pthread symbols without
even us asking for. That breaks old assumption that pthread symbols
are not available on windows.
In order to fix that we detect this condition in configure.ac and
avoid defining windows versions of pthread symbols.
* some variables defined with "char *" should be modified to "const char*"
* For uclibc, glibc's "void malloc_stats(void)" should be "void malloc_stats(FILE *)", is commented now.
* For uclibc, __sbrk is with attribute "hidden", so we use mmap allocator for uclibc.
This merges patch contributed by Jovan Zelincevic.
And with that patch tcmalloc build with --enable-minimal (just malloc
replacement) appears to work (passes unit tests).
Because automake will not automatically add AM_LDFLAGS if there's
per-target LDFLAGS. See their good info manual.
This fixes .dll compilation of tcmalloc
git-svn-id: http://gperftools.googlecode.com/svn/trunk@205 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
I.e. so that I can build tcmalloc.dll using comfortable environment of
my GNU/Linux box and without having to touch actual windows box or VM.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@202 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
This fix is a result of a performance degradation observed in multi-threaded programs where large
amounts of memory (30GB) are consumed, released by a pool of threads in a cyclic manner. This was
mainly due to the amount of time we were spending in the slow path consolidating memory between
the thread cache and central free list. The default has been bumped up to 32768 and is now also
controllable through the TCMALLOC_TRANSFER_NUM_OBJ environment setting.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@193 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
- Used aclocal, autoupdate, autoconf, and automake to correctly apply changes made to Makefile.am. Detailed instructions on this procedure can be found here http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html.
- Fixed a number of error/warning messages due to use of newer aclocal, autoconf, and automake utilities.
- Directly and indirectly related to issue-385 and issue-480.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@173 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
In revisions 151 and 150 an attempt was made to enable frame pointers by default for i386. However, in the process of doing so a number of files were inadvertently touched as a result of running autogen.sh. As a result, I have needed to roll back these revisions so that I can reattempt the change.
git-svn-id: http://gperftools.googlecode.com/svn/trunk@172 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
