Update the tcmalloc vendor branch to r144 (gperftools 2.0), and README.chromium.

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
 environment variables you can use with tcmalloc, as well.
 
 tcmalloc functionality is available on all systems we've tested; see
 INSTALL for more details.  See README_windows.txt for instructions on
 using tcmalloc on Windows.
 
 NOTE: When compiling with programs with gcc, that you plan to link
 with libtcmalloc, it's safest to pass in the flags
 
  -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free
 
 when compiling.  gcc makes some optimizations assuming it is using its
 own, built-in malloc; that assumption obviously isn't true with
 tcmalloc.  In practice, we haven't seen any problems with this, but
 the expected risk is highest for users who register their own malloc
-hooks with tcmalloc (using google/malloc_hook.h).  The risk is lowest
-for folks who use tcmalloc_minimal (or, of course, who pass in the
-above flags :-) ).
+hooks with tcmalloc (using gperftools/malloc_hook.h).  The risk is
+lowest for folks who use tcmalloc_minimal (or, of course, who pass in
+the above flags :-) ).
 
 
 HEAP PROFILER
 -------------
 See doc/heap-profiler.html for information about how to use tcmalloc's
 heap profiler and analyze its output.
 
 As a quick-start, do the following after installing this package:
 
 1) Link your executable with -ltcmalloc
@@ skipping 181 matching lines @@
 Its likeliness increases the more dlopen() commands an executable has.
 Most executables don't have any, though several library routines like
 getgrgid() call dlopen() behind the scenes.
 
 2) On x86-64 64-bit systems, while tcmalloc itself works fine, the
 cpu-profiler tool is unreliable: it will sometimes work, but sometimes
 cause a segfault.  I'll explain the problem first, and then some
 workarounds.
 
 Note that this only affects the cpu-profiler, which is a
-google-perftools feature you must turn on manually by setting the
+gperftools feature you must turn on manually by setting the
 CPUPROFILE environment variable.  If you do not turn on cpu-profiling,
 you shouldn't see any crashes due to perftools.
 
 The gory details: The underlying problem is in the backtrace()
 function, which is a built-in function in libc.
 Backtracing is fairly straightforward in the normal case, but can run
 into problems when having to backtrace across a signal frame.
 Unfortunately, the cpu-profiler uses signals in order to register a
 profiling event, so every backtrace that the profiler does crosses a
 signal frame.
@@ skipping 15 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