Update the tcmalloc chromium branch to r144 (gperftools 2.0), and merge chromium-specific changes.

third_party/tcmalloc/chromium/src/thread_cache.h

Index: third_party/tcmalloc/chromium/src/thread_cache.h
diff --git a/third_party/tcmalloc/chromium/src/thread_cache.h b/third_party/tcmalloc/chromium/src/thread_cache.h
index d631f45284f9e817d883dcf7df450b7b7c49fe8d..0c5be073703bdf3b6f2739e9e95786f304c1d94a 100644
--- a/third_party/tcmalloc/chromium/src/thread_cache.h
+++ b/third_party/tcmalloc/chromium/src/thread_cache.h
@@ -88,7 +88,6 @@ class ThreadCache {
   void Deallocate(void* ptr, size_t size_class);
 
   void Scavenge();
-  void Print(TCMalloc_Printer* out) const;
 
   int GetSamplePeriod();
 
@@ -125,10 +124,6 @@ class ThreadCache {
   // REQUIRES: Static::pageheap_lock is held.
   static void GetThreadStats(uint64_t* total_bytes, uint64_t* class_count);
 
-  // Write debugging statistics to 'out'.
-  // REQUIRES: Static::pageheap_lock is held.
-  static void PrintThreads(TCMalloc_Printer* out);
-
   // Sets the total thread cache size to new_size, recomputing the
   // individual thread cache sizes as necessary.
   // REQUIRES: Static::pageheap lock is held.
@@ -214,6 +209,10 @@ class ThreadCache {
       return FL_Pop(&list_);
     }
 
+    void* Next() {
+      return SLL_Next(&list_);

[jar (doing other things), 2012/02/28 22:15:49]

Probably add FL_Next() instead of SLL_next.

[Dai Mikurube (NOT FULLTIME), 2012/02/28 23:05:43]

Done.

+    }
+
     void PushRange(int N, void *start, void *end) {
       FL_PushRange(&list_, start, end);
       length_ += N;
@@ -366,6 +365,12 @@ inline void ThreadCache::Deallocate(void* ptr, size_t cl) {
   FreeList* list = &list_[cl];
   size_ += Static::sizemap()->ByteSizeForClass(cl);
   ssize_t size_headroom = max_size_ - size_ - 1;
+
+  // This catches back-to-back frees of allocs in the same size
+  // class. A more comprehensive (and expensive) test would be to walk
+  // the entire freelist. But this might be enough to find some bugs.
+  ASSERT(ptr != list->Next());

[jar (doing other things), 2012/03/01 01:35:05]

Since you're having trouble with this assert... I looked closer... and it looks
to be correct to use FL_Next() in the  implementation of Next().

The list that we got is a FreeList found in line 365.  That list should be
completely well formed.  (i.e., there is no chance this is just a partially
formed list mis-firing an assertion).

The assertion in the implementation of FL_Next() (which we forward Next() into)
first checks (without asserting) if there is a next item, and if so, then it
traps if the follower does not point back to the current item via a prev link. 
That should definitely be valid in the heap (where we found the free list) at
all times.  It should be a nice clean invariant.

[Dai Mikurube (NOT FULLTIME), 2012/03/01 01:54:05]

Thanks, Jim.

I agree.  It looks that the list SHOULD be well formed at all times (at least at
the ASSERT).  But, I observed a case that :

FL_Previous_No_Check(FL_Next_No_Check(t)) != t
(i.e. FL_Previous_No_Check(FL_Next_No_Check(t)) == NULL
   && FL_Next_No_Check(t) != NULL)

at FL_Next() while I was diving with gdb into the code ONLY with the ASSERT
(http://codereview.chromium.org/9528002/).

If my observation is correct, it may be a real corruption... I'm looking at this
deeper.


On 2012/03/01 01:35:05, jar wrote:

+
   list->Push(ptr);
   ssize_t list_headroom =
       static_cast<ssize_t>(list->max_length()) - list->length();