Update the tcmalloc vendor branch to r111 (perftools version 1.8)

third_party/tcmalloc/vendor/README

 IMPORTANT NOTE FOR 64-BIT USERS
 -------------------------------
 There are known issues with some perftools functionality on x86_64
 systems.  See 64-BIT ISSUES, below.
 
 
 TCMALLOC
 --------
 Just link in -ltcmalloc or -ltcmalloc_minimal to get the advantages of
 tcmalloc -- a replacement for malloc and new.  See below for some
@@ skipping 186 matching lines @@
     ___tls_get_addr: symbol not found
 
 This means that you have a system where some parts are updated enough
 to support Thread Local Storage, but others are not.  The perftools
 configure script can't always detect this kind of case, leading to
 that error.  To fix it, just comment out (or delete) the line
    #define HAVE_TLS 1
 in your config.h file before building.
 
 
-OS X ISSUES
------------
-
-You may need to set the environment variable DYLD_FORCE_FLAT_NAMESPACE
-to use perftools with OS X.  Because of how OS X does symbol binding,
-libc routines will use libc malloc even when the binary is linked with
--ltcmalloc.  This is not usually a problem, but becomes one if the
-application is responsible for freeing that memory: the application
-will use tcmalloc's free() to try to free memory allocated with libc's
-malloc(), which will cause no end of confusion.
-
-One (or both) of these workaround may fix the problem:
-    DYLD_FORCE_FLAT_NAMESPACE=1 myapp
-    DYLD_INSERT_LIBRARIES=path/to/libtcmalloc.dylib myapp
-
-The best solution may depend on the version of OS X being used.
-Neither solution is likely to work if you dlopen() libraries from
-within your application.  If you have any experience with this, we'd
-appreciate you sharing it at
-   http://groups.google.com/group/google-perftools
-
-
 64-BIT ISSUES
 -------------
 
 There are two issues that can cause program hangs or crashes on x86_64
 64-bit systems, which use the libunwind library to get stack-traces.
 Neither issue should affect the core tcmalloc library; they both
 affect the perftools tools such as cpu-profiler, heap-checker, and
 heap-profiler.
 
 1) Some libc's -- at least glibc 2.4 on x86_64 -- have a bug where the
@@ skipping 39 matching lines @@
 your code, rather than setting CPUPROFILE.  This will profile only
 those sections of the codebase.  Though we haven't done much testing,
 in theory this should reduce the chance of crashes by limiting the
 signal generation to only a small part of the codebase.  Ideally, you
 would not use ProfilerStart()/ProfilerStop() around code that spawns
 new threads, or is otherwise likely to cause a call to
 pthread_mutex_lock!
 
 ---
 17 May 2011