Try fixing virtual memory regression by new tcmalloc.

third_party/tcmalloc/chromium/src/common.h

Index: third_party/tcmalloc/chromium/src/common.h
diff --git a/third_party/tcmalloc/chromium/src/common.h b/third_party/tcmalloc/chromium/src/common.h
index 4f848fa2f01013cf53931cf42b354c460d6585d5..19c142ba449469da7c3797bcc7a4d95afa98a35d 100644
--- a/third_party/tcmalloc/chromium/src/common.h
+++ b/third_party/tcmalloc/chromium/src/common.h
@@ -79,14 +79,15 @@ static const size_t kSkippedClasses = (kAlignment < kMinClassSize ? 1 : 0);
 static const size_t kPageShift  = 15;
 static const size_t kNumClasses = 78 - kSkippedClasses;
 #else
-static const size_t kPageShift  = 13;
+// Chromium tunes kPageShift: 13 -> 12. (page size 8k -> 4k)
+static const size_t kPageShift  = 12;
 static const size_t kNumClasses = 86 - kSkippedClasses;

[jar (doing other things), 2012/03/15 19:36:49]

I have the recollection we used to have fewer classes as well (some where close
to 60 or 64).  How does this all work out??  I think the scaling factor between
classes used to be 1.125 (1 + 1/8th).  Does this change when we have additional
classes?

[Dai Mikurube (NOT FULLTIME), 2012/03/15 20:17:32]

It fails at an assertion in common.cc...  I sent a try with a new value 54.

 #endif
 static const size_t kMaxThreadCacheSize = 4 << 20;
 
 static const size_t kPageSize   = 1 << kPageShift;
-// TODO(dmikurube): We Chromium may want to tune this kMaxSize.
-static const size_t kMaxSize    = 256 * 1024;
+// Chromium tunes kMaxSize: 256 * 1024 -> 8u * kPageSize (256k -> 32k)

[jar (doing other things), 2012/03/15 19:36:49]

Please use prose, rather than the symbolic "->" to try to mean  "changed to" or
something.  For instance, you might say:

Original TCMalloc code used kMaxSize == 256 * 1024.  In Chrome, we changed this
to 32K, and represent it in terms of page size (as was done in prior versions of
TCMalloc).

[Dai Mikurube (NOT FULLTIME), 2012/03/15 20:17:32]

Done.

+static const size_t kMaxSize    = 8u * kPageSize;
 // For all span-lengths < kMaxPages we keep an exact-size list.
 static const size_t kMaxPages = 1 << (20 - kPageShift);
 
@@ -177,8 +178,9 @@ class SizeMap {
   //   ...
   //   32768      (32768 + 127 + (120<<7)) / 128  376
   static const int kMaxSmallSize = 1024;
+  // Chromium tunes kClassArraySize.
   static const size_t kClassArraySize =
-      ((kMaxSize + 127 + (120 << 7)) >> 7) + 1;
+      (((1 << kPageShift) * 8u + 127 + (120 << 7)) >> 7) + 1;

[jar (doing other things), 2012/03/15 19:36:49]

I don't think you need to change this line.  I think it is derived from the
constant.  In fact, in this case,
kPageShift == 12
so (line 88) PageSize == 1 << kPageShift == 4K
Hence this change (highlighted) is indeed 32K,
and the old code:
kMaxSize == 8u * kPageSize  
would also have been 32K.

Why did you decide this was a better way of stating this, than the current
TCMalloc code?

[Dai Mikurube (NOT FULLTIME), 2012/03/15 20:17:32]

I thought keeping the original code implies the original authors' thoughts, if
we use the old code.  But, using kMaxSize sounds better here.

   unsigned char class_array_[kClassArraySize];
 
   // Compute index of the class_array[] entry for a given size