Updated the third_party/tcmalloc/vendor revision to r87.

This change should not affect any Chromium builds.

TBR=willchan, sgk
Review URL: http://codereview.chromium.org/570021

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38090 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 14 insertions, 0 deletions

diff --git a/third_party/tcmalloc/vendor/README.windows b/third_party/tcmalloc/vendor/README.windows
index 2cc607f..750aa51 100644
--- a/third_party/tcmalloc/vendor/README.windows
+++ b/third_party/tcmalloc/vendor/README.windows
@@ -51,6 +51,7 @@ Optimization (FPO) is enabled -- that is, in release mode.  The other
 features of perftools, such as the cpu-profiler and leak-checker, have
 not yet been ported to Windows at all.
 
+
 NOTE FOR WIN2K USERS: According to reports
 (http://code.google.com/p/google-perftools/issues/detail?id=127)
 the stack-tracing necessary for the heap-profiler does not work on
@@ -59,6 +60,19 @@ 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