Merge tcmalloc r111 (perftools v. 1.8) with the chromium/ branch.

Merge tcmalloc r111 (perftools v. 1.8) with the chromium/ branch.

[Alexander Potapenko, 2011-07-28 14:19:19]

Will,

here's the merge containing the Mac OS bits.

Please pay specific attention to the following files:
http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
-- I've removed the SysAllocator object which was added to fix the problems with
Windows build in r109
http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
-- the TC_VERSION_* macros moved to
http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
-- I had to disable the replacements for new/malloc/etc. because we already have
them in allocator_shim. Maybe you've got a better idea of how to fix this?

[willchan no longer on Chromium, 2011-07-29 08:33:39]

I'm switching Jim to be the primary reviewer here. Jim, let me know if you don't
want this.

[jar (doing other things), 2011-07-31 08:19:39]

A lot of this appears to relate to a recent suggestion about tuning TCMalloc, as
mentioned on a recent thread.  Have those tunings become main-stream (the paper
seemed to list them tentatively... but maybe the paper is outdated??).

I probably need to look even more closely at this, but I wanted to give some
feedback.

I'd be very interested in hearing if this CL had an immediate impact (fearing
the worst) on the perf-bots for Chrome.  Have you tried to land and revert this
patch set during an evening to see what the impact is? (Please try to land a
only a related CL, using the diff file, so that we don't lose our comment
history on this CL).

It would be much nicer if these new tunings were better controlled by #ifdefs,
the way LARGE_PAGE use is.

I strongly suspect some of these tunings are better suited to server utilization
of TCMalloc... and I'd like to talk through the impact a bit more before landing
it.

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
File third_party/tcmalloc/chromium/src/base/spinlock_internal.cc (right):

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/base/spinlock_internal.cc:47: #elif
defined(__linux__) && !defined(__native_client__)
I was expecting items provided by more mainstream TCMalloc.  This looks like a
Chromium specific change.  

Was this added because we couldn't compile new stuff without this change?

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
File third_party/tcmalloc/chromium/src/central_freelist.h (right):

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/central_freelist.h:74: // page full of 5-byte
objects would have 2 bytes memory overhead).
This commment is confusing... but perhaps you're just porting a questionable
comment?

The example makes it sound like this is fragmentation due to left over bytes
during span carving.  The description says this has to do with freelists, which
seem very orthogonal.

Is this just a comment you merged into place?

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
File third_party/tcmalloc/chromium/src/common.cc (right):

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/common.cc:125: // Continue to add pages until
there are at least as many objects in
I'm not clear on the justification for doing this.
Yes, it will help when we do the *first* allocation (and we had nothing). 
However, when we have some left-over in the central cache, but not enough to
satisfy a request from a thread, this will seemingly lead to over-allocation (so
as to avoid a second call??).  I'd like to better understand the motivation.

<sigh>... but glancing at the code in line 116, perhaps this is actually 1/4th
of the amount we typically move... which would be sensible.  I need to look at
the definition and use of NumMoveSize().

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
File third_party/tcmalloc/chromium/src/common.h (right):

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/common.h:68: static const size_t kPageShift  =
13;
This is the change to 8K pages from 4K.  The recent paper suggests this works
well for servers, but we really need to tune this for Chrome (or at least watch
that we don't see a regression when we land this).

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/common.h:71: static const size_t
kMaxThreadCacheSize = 4 << 20;
This looks like another change (for us, since we don't use LARGE_PAGES).  I
don't recall seeing a justification for this tuning change.

http://codereview.chromium.org/7430007/diff/18014/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/common.h:74: static const size_t kMaxSize    =
256 * 1024;
This is a big tuning change, upping the cutoff point to 256K from 32K.
Although we allocate IO buffers of 32K size, I don't think we do much larger
allocating.  Also, the 32K allocations will now be carved, and might not be
coalesced to spans and returned to the OS... which would notably raise our
committed memory footprint.

This tuning change is especially unclear for us on Chrome (unless I'm
mis-remembering the algorithms and mis-guessing the impact)