Revert 126715 - Update the tcmalloc vendor branch to r144 (gperftools 2.0).

third_party/tcmalloc/vendor/README_windows.txt

 --- COMPILING
 
 This project has begun being ported to Windows.  A working solution
 file exists in this directory:
-    gperftools.sln
+    google-perftools.sln
 
 You can load this solution file into VC++ 7.1 (Visual Studio 2003) or
 later -- in the latter case, it will automatically convert the files
 to the latest format for you.
 
 When you build the solution, it will create a number of unittests,
 which you can run by hand (or, more easily, under the Visual Studio
 debugger) to make sure everything is working properly on your system.
 The binaries will end up in a directory called "debug" or "release" in
 the top-level directory (next to the .sln file).  It will also create
@@ skipping 55 matching lines @@
 
 
 --- WIN64
 
 The function-patcher has to disassemble code, and is very
 x86-specific.  However, the rest of perftools should work fine for
 both x86 and x64.  In particular, if you use the 'statically link with
 libc, and replace its malloc with tcmalloc' approach, mentioned above,
 it should be possible to use tcmalloc with 64-bit windows.
 
-As of perftools 1.10, there is some support for disassembling x86_64
-instructions, for work with win64.  This work is preliminary, but the
-test file preamble_patcher_test.cc is provided to play around with
-that a bit.  preamble_patcher_test will not compile on win32.
-
 
 --- ISSUES
 
 NOTE FOR WIN2K USERS: According to reports
-(http://code.google.com/p/gperftools/issues/detail?id=127)
+(http://code.google.com/p/google-perftools/issues/detail?id=127)
 the stack-tracing necessary for the heap-profiler does not work on
 Win2K.  The best workaround is, if you are building on a Win2k system
 is to add "/D NO_TCMALLOC_SAMPLES=" to your build, to turn off the
 stack-tracing.  You will not be able to use the heap-profiler if you
 do this.
 
 NOTE ON _MSIZE and _RECALLOC: The tcmalloc version of _msize returns
 the size of the region tcmalloc allocated for you -- which is at least
 as many bytes you asked for, but may be more.  (btw, these *are* bytes
 you own, even if you didn't ask for all of them, so it's correct code
 to access all of them if you want.)  Unfortunately, the Windows CRT
 _recalloc() routine assumes that _msize returns exactly as many bytes
 as were requested.  As a result, _recalloc() may not zero out new
 bytes correctly.  IT'S SAFEST NOT TO USE _RECALLOC WITH TCMALLOC.
 _recalloc() is a tricky routine to use in any case (it's not safe to
 use with realloc, for instance).
 
 
 I have little experience with Windows programming, so there may be
 better ways to set this up than I've done!  If you run across any
 problems, please post to the google-perftools Google Group, or report
-them on the gperftools Google Code site:
+them on the google-perftools Google Code site:
    http://groups.google.com/group/google-perftools
-   http://code.google.com/p/gperftools/issues/list
+   http://code.google.com/p/google-perftools/issues/list
 
 -- craig
 
-Last modified: 2 February 2012
+Last modified: 6 April 2011