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.
Editing the options passed to curl via 'my @URL_FETCHER = ("curl",
"-s");' (in particular to add a -k to ignore self signed certs) fails
for some invocations of curl. In FetchDynamicProfile, 'my @fetcher =
AddFetchTimeout($fetch_timeout, @URL_FETCHER);' ends up being just
'curl' if timeout is not defined.
This happens because AddFetchTimeout doesn't retrieve all the arguments
from the caller.
[alk@tut.by: updated commit message]
Signed-off-by: Aliaksey Kandratsenka <alk@tut.by>
Clang's recent focus on code size doesn't help us in malloc fast-path
because somehow clang completely ignores inline directives.
In order to help clang generate code that was actually intended by
original authors, we're adding always_inline attribute to key
fast-path functions.
Clang also guessed likely branch "wrong" in couple places. Which is
now addressed by UNLIKELY declarations there.
While standards do not require us to set errno to ENOMEM in certain
places (like posix_memalign), existing code may sometimes set it
(i.e. because mmap or sbrk couldn't get memory from kernel)
anyways. And from my reading of glibc, it's malloc is doing more or
less same by just always setting ENOMEM on OOM condition.
This commit also eliminates some functions (XXX_no_errno) that are not
needed anymore.
This commit removes 4 (four!) duplicates of C++ OOM handling. And
introduces one helper for that.
Other change is that malloc doesn't have to check tc_new_mode anymore
until it _actually_ deals with OOM condition. Which shaves off couple
instructions from fast-path.
gcc 5 has got nice new optimization (-fipa-icf) which merges identical
functions into one. And that causes heap-profiler_unittest to fail
since it expects to see both Allocate and Allocate2 in heap
profiles. And smart GCC detects that they are same function and makes
one function out of two and thus breaks this test.
New code simply adds (disabled) logging calls to make those functions
non-identical.
GCC 5 ended up too smart and optimized out assignment of allocated
block to global variable. Which caused test to fail since it triggered
unexpected "leak".
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.
This is patch by user mitchblank.
From his words:
The problem is pretty simple. Ancient C code allowed declarations
without argument prototypes, i.e.
int foo();
For compatibility this is still accepted. If you want to declare a
function with zero prototypes the correct way to do it is:
int foo(void);
C++ also accepts this syntax, but it's not needed there.
Normally compilers still accept the old-style entries, but with
sufficient warning flags gcc will complain about them. It is good for
header files to have the explicit "void" argument so all compilers are
kept happy.
I'm attaching a simple patch to add the "void" parameter to that file.
I haven't checked if other headers have the same problem (I'm just
using the profiler at the moment)
<end of quote>
In fact "int foo()" means "foo accepts any args" and we really want
"foo has no args". For which int foo (void) is right declaration.
Because sys_futex actually takes 6 args in more recent kernels (even
though last two args are unused for FUTEX_{WAKE,WAIT}.
This is patch contributed by user spotrh.
This is contributed by Paolo Bonzini.
This commit adds TCMALLOC_TRACE_FILE environment variable, which if
defined overrides location of malloc trace file.
Clang 3.5 has a warning about deleting objects with virtual methods
through non-virtual destructors which was triggered. I'm not sure
whether this actually creates any undefined or otherwise incorrect
behavior, but it seems like a good thing to fix regardless.
Example compiler warning:
third_party/gperftools/src/tests/profile-handler_unittest.cc:282:5: error:
delete called on '(anonymous namespace)::BusyThread' that has virtual
functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
delete busy_worker_;
^
Which both enables per-thread timers and allows the signal number for
the timer to be selected.
[alk@tut.by: reformatted commit message for subject line length]
Signed-off-by: Aliaksey Kandratsenka <alk@tut.by>