Support use of third party time function to profiler

Support use of third party time function for about:profiler

This uses TCMalloc to provide a time function, allowing
us to see how much memory was allocated on a single thread
during the running of a task.  The alternate time function
is put in place only when a specific environment variable
is detected during TCMalloc startup.

This change currently is activated only in Windows/Linux,
as it is based on changes TCMalloc (not used on Mac).

We also create an infrastructure for using any alternate
timer, to replace the "wall clock time," on a per-thread
basis, in the about:profiler infrastructure.  That interface
may be used on other platforms, including scenarios where
we have a per-thread-CPU-time function to replace the
wall-clock timer.  In all cases, when this alternate timer
is activated, we lose the ability to calculated queueing
time.  Queueing time is based on a time snapshot taken on
a second thread, and hence is not comparable to the
alternate timer (when the alternate timer is engaged).


r=rtenneti
BUG=103321
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=122180

[jar (doing other things), 2012-02-14 02:52:04]

Will,

Since I'm hacking away at TCMalloc here, I thought perchance you could keep me
honest, or suggest better ways of doing things if you felt I was too far from
some basic religion.  Please focus on the files in the TCMalloc area.

Raman,

I was hoping you could review code that was outside the TCmalloc core.

Thanks in advance!

[willchan no longer on Chromium, 2012-02-15 01:29:56]

http://codereview.chromium.org/9212025/diff/46001/third_party/tcmalloc/chromi...
File third_party/tcmalloc/chromium/src/thread_cache.h (right):

http://codereview.chromium.org/9212025/diff/46001/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/thread_cache.h:305: // Chromium profiling.
You should comment more what this is. In particular, I see that you are counting
the real bytes allocated (including rounding to size class), not the
user-requested bytes allocated.

[jar (doing other things), 2012-02-15 02:05:08]

Comment added per request by WillChan.

http://codereview.chromium.org/9212025/diff/46001/third_party/tcmalloc/chromi...
File third_party/tcmalloc/chromium/src/thread_cache.h (right):

http://codereview.chromium.org/9212025/diff/46001/third_party/tcmalloc/chromi...
third_party/tcmalloc/chromium/src/thread_cache.h:305: // Chromium profiling.
On 2012/02/15 01:29:56, willchan wrote:
> You should comment more what this is. In particular, I see that you are
counting
> the real bytes allocated (including rounding to size class), not the
> user-requested bytes allocated.

Done.

[willchan no longer on Chromium, 2012-02-15 17:33:54]

third_party/tcmalloc changes LGTM

I did not review base/.

Btw, in what way is this Windows only (that's what the changelist description
claims)?

[jar (doing other things), 2012-02-15 17:43:49]

re: Windows only(?)

I *think* that the TCMalloc code used in Windows might actually be distinct from
the code used in Linux (or at least I was recently confused about how many
copies of the TCMalloc code we have in our src/thirdparty/tcmalloc/*
subdirectories).  If we are truly sharing code, then this is a Windows and Linux
change (Mac does not use TCMalloc).

I currently see a (suprising) three copies of the tcmalloc source in our tree. 
For instance, you can find in thirdparty/tcmalloc:

chromimum/src/thread_cache.cc
tcmalloc/src/thread_cache.cc
vendor/src/thread_cache.cc

I would have expected to see at most two copies of each file, one to show our
branch point, and one to show what we've patched (predominantly in windows).  I
suspect the third copy is used in Linux.... and I assumed you introduced it when
you got Linux into this game.... but perchance my assumptions are way out of
whack.


On 2012/02/15 17:33:54, willchan wrote:
> third_party/tcmalloc changes LGTM
> 
> I did not review base/.
> 
> Btw, in what way is this Windows only (that's what the changelist description
> claims)?

[willchan no longer on Chromium, 2012-02-15 18:00:32]

On Wed, Feb 15, 2012 at 9:43 AM, <[email protected]> wrote:

> re: Windows only(?)
>
> I *think* that the TCMalloc code used in Windows might actually be
> distinct from
> the code used in Linux (or at least I was recently confused about how many
> copies of the TCMalloc code we have in our src/thirdparty/tcmalloc/*
> subdirectories).  If we are truly sharing code, then this is a Windows and
> Linux
> change (Mac does not use TCMalloc).
>

I think we share code. Glider did a lot of work to unfork the Linux code,
so we are sharing the code in src/ other than src/windows/ which replaces
some stuff.


>
> I currently see a (suprising) three copies of the tcmalloc source in our
> tree.
> For instance, you can find in thirdparty/tcmalloc:
>
> chromimum/src/thread_cache.cc
> tcmalloc/src/thread_cache.cc
>

Where's this tcmalloc/src/thread_cache.cc? Is this a very old client of
yours? I suspect it doesn't actually exist in the svn repo anymore.


> vendor/src/thread_cache.cc
>
> I would have expected to see at most two copies of each file, one to show
> our
> branch point, and one to show what we've patched (predominantly in
> windows).  I
> suspect the third copy is used in Linux.... and I assumed you introduced
> it when
> you got Linux into this game.... but perchance my assumptions are way out
> of
> whack.
>
>
>
> On 2012/02/15 17:33:54, willchan wrote:
>
>> third_party/tcmalloc changes LGTM
>>
>
>  I did not review base/.
>>
>
>  Btw, in what way is this Windows only (that's what the changelist
>> description
>> claims)?
>>
>
>
>
>
http://codereview.chromium.**org/9212025/<http://codereview.chromium.org/9212...
>

[jar (doing other things), 2012-02-15 18:16:13]

You are correct.  The src/third_party/tcmalloc/tcmalloc subtree is not part of
our chromium tree, even though I have it in *two* distinct trees on my windows
box.  It appears to be an svn tree from the upstream repository, that I (must
have??) pulled at some point in development, and left in place just to confuse
myself:

$ svn info tcmalloc
Path: tcmalloc
URL: http://google-perftools.googlecode.com/svn/trunk
Repository Root: http://google-perftools.googlecode.com/svn
Repository UUID: e123bbac-8519-0410-9389-e36bf2bdbbd6
Revision: 77
Node Kind: directory
Schedule: normal
Last Changed Author: csilvers
Last Changed Rev: 77
Last Changed Date: 2009-10-27 10:30:52 -0700 (Tue, 27 Oct 2009)

Sorry for injecting confusion into this bug... but at least this clears up my
tree ;-).

On 2012/02/15 18:00:32, willchan wrote:
> On Wed, Feb 15, 2012 at 9:43 AM, <mailto:[email protected]> wrote:
> 
> > re: Windows only(?)
> >
> > I *think* that the TCMalloc code used in Windows might actually be
> > distinct from
> > the code used in Linux (or at least I was recently confused about how many
> > copies of the TCMalloc code we have in our src/thirdparty/tcmalloc/*
> > subdirectories).  If we are truly sharing code, then this is a Windows and
> > Linux
> > change (Mac does not use TCMalloc).
> >
> 
> I think we share code. Glider did a lot of work to unfork the Linux code,
> so we are sharing the code in src/ other than src/windows/ which replaces
> some stuff.
> 
> 
> >
> > I currently see a (suprising) three copies of the tcmalloc source in our
> > tree.
> > For instance, you can find in thirdparty/tcmalloc:
> >
> > chromimum/src/thread_cache.cc
> > tcmalloc/src/thread_cache.cc
> >
> 
> Where's this tcmalloc/src/thread_cache.cc? Is this a very old client of
> yours? I suspect it doesn't actually exist in the svn repo anymore.
> 
> 
> > vendor/src/thread_cache.cc
> >
> > I would have expected to see at most two copies of each file, one to show
> > our
> > branch point, and one to show what we've patched (predominantly in
> > windows).  I
> > suspect the third copy is used in Linux.... and I assumed you introduced
> > it when
> > you got Linux into this game.... but perchance my assumptions are way out
> > of
> > whack.
> >
> >
> >
> > On 2012/02/15 17:33:54, willchan wrote:
> >
> >> third_party/tcmalloc changes LGTM
> >>
> >
> >  I did not review base/.
> >>
> >
> >  Btw, in what way is this Windows only (that's what the changelist
> >> description
> >> claims)?
> >>
> >
> >
> >
> >
>
http://codereview.chromium.**org/9212025/%3Chttp://codereview.chromium.org/92...>
> >

[ramant (doing other things), 2012-02-15 18:33:46]

lgtm

http://codereview.chromium.org/9212025/diff/52003/base/profiler/alternate_tim...
File base/profiler/alternate_timer.h (right):

http://codereview.chromium.org/9212025/diff/52003/base/profiler/alternate_tim...
base/profiler/alternate_timer.h:23: // Gets the pointer to a function that was
set SetAlternateTimeSource().
nit: set SetAlternateTimeSource -> set in SetAlternateTimeSource (may be ??)

http://codereview.chromium.org/9212025/diff/52003/base/profiler/alternate_tim...
base/profiler/alternate_timer.h:24: // Returns NULL if no set was done prior to
calling GetAlternateTimeSource
nit: missing period.

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc
File base/tracked_objects.cc (right):

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:40: // the ThreadData class.  This compile time flag
should be set to try if we want
nit: try -> true

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:48: static const char k_alternate_profile_timer[] =
"CHROME_PROFILER_TIME";
nit: should we consider commenting that "k_alternate_profile_timer" is declared
at two places (here and base/allocator/allocator_shim.cc) and if one changes it
at one place, that they should consider changing at the other place?

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:615: ThreadData::SetAlternateTimeSource(now_function);
nit: should we consider moving the following check into SetAlternateTimeSource?
(wondered while reading SetAlternateTimeSource if we should have a DCHECK for
now_function) thanks

if (!now_function)
      break;

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:643: // doing this work.
Wondered if "_heap_init" happens before ThreadData::Initialize. (I am guessing
it does).

[jar (doing other things), 2012-02-15 20:26:31]

Changes made per comments by rtenneti.

If this gets a set of green try bots, I'll land it.

Thanks!

http://codereview.chromium.org/9212025/diff/52003/base/profiler/alternate_tim...
File base/profiler/alternate_timer.h (right):

http://codereview.chromium.org/9212025/diff/52003/base/profiler/alternate_tim...
base/profiler/alternate_timer.h:23: // Gets the pointer to a function that was
set SetAlternateTimeSource().
On 2012/02/15 18:33:46, ramant wrote:
> nit: set SetAlternateTimeSource -> set in SetAlternateTimeSource (may be ??)

Done.

http://codereview.chromium.org/9212025/diff/52003/base/profiler/alternate_tim...
base/profiler/alternate_timer.h:24: // Returns NULL if no set was done prior to
calling GetAlternateTimeSource
On 2012/02/15 18:33:46, ramant wrote:
> nit: missing period.

Done.

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc
File base/tracked_objects.cc (right):

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:40: // the ThreadData class.  This compile time flag
should be set to try if we want
On 2012/02/15 18:33:46, ramant wrote:
> nit: try -> true

Done.  I added a lot of text to try to be even clearer... please have another
look.

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:48: static const char k_alternate_profile_timer[] =
"CHROME_PROFILER_TIME";
I went back and tried to move it to shared place.  I think it will now work ;-).
 Thanks for reminding/pushing me!

On 2012/02/15 18:33:46, ramant wrote:
> nit: should we consider commenting that "k_alternate_profile_timer" is
declared
> at two places (here and base/allocator/allocator_shim.cc) and if one changes
it
> at one place, that they should consider changing at the other place?

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:615: ThreadData::SetAlternateTimeSource(now_function);
On 2012/02/15 18:33:46, ramant wrote:
> nit: should we consider moving the following check into
SetAlternateTimeSource?
> (wondered while reading SetAlternateTimeSource if we should have a DCHECK for
> now_function) thanks
> 
> if (!now_function)
>       break;

Done.

http://codereview.chromium.org/9212025/diff/52003/base/tracked_objects.cc#new...
base/tracked_objects.cc:643: // doing this work.
heap_init is run super-duper-early, before *any* allocations are done.  As a
result, we can trust that IF it gets run at all, it is done by now.

On 2012/02/15 18:33:46, ramant wrote:
> Wondered if "_heap_init" happens before ThreadData::Initialize. (I am guessing
> it does).

[ramant (doing other things), 2012-02-15 22:31:17]

lgtm