Depending on things such us strlen, which are ifunc-ed themselves is
not supported from inside ifunc handler.
Thus we implement strlen, memchr and memcmp in slow naive C++ just for
that place.
Previously we bumped size by 16 between iterations, but for many size
classess that gave is subsequent iteration into same size
class. Multiplying by prime number randomizes sizes more so speeds up
this benchmark on at least modern x86.
We used to decommit (with MADV_FREE or MADV_DONTNEED) whole combined
span when freeing span in aggressive decommit mode. The issue with
that is preceding or following span with which we combined span we're
freeing could be freed already and fairly large. By passing all of
that memory to decommit, we force kernel to scan all of those pages.
When mass-freeing many objects old behavior led to O(N^2) behavior
since freeing single span could lead to MADV_{FREE,DONTNEED}-ing of
most of the heap.
New implementation just does decommit of individual bits as needed.
While there, I'm also adding locking to calls of
PageHeap::{Get,Set}AggressiveDecommit.
This partially (or mostly) fixes issue #839.
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.
We're initializing them with value that doesn't fit into signed 32-bit
int and somehow mingw version that I have not just warns, but actually
errors on that.
Weirdly, some OSX compiler does allow -fsized-deallocation, yet barks
on any attempt to actually use it at compile time (!). So lets detect
this as well in configure and opt out as necessary.
Should fix issue #870.
Since we're not building with hidden visibility, symbols of other DSOs
can interpose our symbols. And sys_alloc is just too generic name.
And in fact erlang runtime has sys_alloc function. Which means we're
trying to write to it's first bytes as part of initializing system
allocator and crash.
This should fix issue #843.
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.
Looks like _free_base is used as generic free/delete, which is not
checked for free/delete mismatch by their debug runtime. Issue #817
occurs because something that is allocated by regular allocation
functions (new or malloc) is freed by _free_base. Patch it as well fixes
the problem.
Closes#817.
This is taken from jemalloc patch at
19c9a3e828
by Mike Hommey (aka glandium).
The issue was reported together with advise to take that jemalloc fix by
Koichi Shiraishi and David Ribeiro Alves at gperftools issue #827.
Closes issue #827.
glibc deprecated malloc hooks in 2011 and will be removing them soon.
These hooks aren't safe and aren't necessary when the malloc API is
fully exported.
Clang actually does support __atomic_XXX atomic ops builtins but does
not advertise itselt as gcc 4.7 or later. So we now detect clang
separetely.
We're enabling gcc atomic ops on clang >= 3.4 since this is the oldest
version that I can test.
This should fix issue #797.
node.js extensions are regular shared libraries named with the `.node` extension. With this small change I was able to get a usable heap profile out of node to debug an extension I'm working on.
If we don't do it, then reading variable calls to __tls_get_addr, which
uses malloc on first call. initial-exec makes dynamic linker reserve tls
offset for recusion flag early and thus avoid unsafe calls to malloc.
This fixes issue #786.
Building with -DTCMALLOC_USE_MADV_FREE will enable usage of MADV_FREE on
Linux if glibc copy of kernel headers has MADV_FREE defined.
I.e. so that people can test this more easily.
Affects ticket #780.
