Track parent-child relations during profiling

Propogate status setting for profiler to track parents

This allows child processes to track ancestry, and report
it to the browser process.

Parent tracking is only turned on based on an 
environment variable.

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

[jar (doing other things), 2012-01-28 00:18:00]

Raman,

This supports communicating of status that we are tracking parent-child
relationships across sub processes (like the browser and plugin processes).

I expect this data to be most useful to developers, and probably won't every be
enabled by default, or uploaded via UMA, since it is relatively "constant" for a
given platform/version.  I do think that I should be able to extend the
visualizations in JS to show some minimal hierarchical profiles (all costs of
task, and its sub-tasks??), but that will be in future CLs.

Thanks in advance,

Jim

[ramant (doing other things), 2012-01-28 02:09:55]

LGTM

http://codereview.chromium.org/9181002/diff/38019/chrome/browser/chrome_brows...
File chrome/browser/chrome_browser_main.cc (right):

http://codereview.chromium.org/9181002/diff/38019/chrome/browser/chrome_brows...
chrome/browser/chrome_browser_main.cc:1167:
tracked_objects::ThreadData::InitializeAndSetTrackingStatus(status);
nit: It looks like this change calls InitializeAndSetTrackingStatus when
kEnableProfiling command line is not passed in. Hope that is intentional.

[jar (doing other things), 2012-01-30 20:41:56]

Reply to comment by rtennneti.

http://codereview.chromium.org/9181002/diff/38019/chrome/browser/chrome_brows...
File chrome/browser/chrome_browser_main.cc (right):

http://codereview.chromium.org/9181002/diff/38019/chrome/browser/chrome_brows...
chrome/browser/chrome_browser_main.cc:1167:
tracked_objects::ThreadData::InitializeAndSetTrackingStatus(status);
Lazy initialization really gets tracked_objects going (during the first call to
profile a task).  This call used to just provide the chance to cancel profiling
real early, and now it allows it to increase the amount of profiling... so I
decided I might as well make the code simpler and always call to initialize
(even if it is redundant).

On 2012/01/28 02:09:55, ramant wrote:
> nit: It looks like this change calls InitializeAndSetTrackingStatus when
> kEnableProfiling command line is not passed in. Hope that is intentional.

[jar (doing other things), 2012-02-06 23:15:04]

John,

Looking for an OWNER review for content.

Thanks!

[jam, 2012-02-06 23:44:07]

content lgtm with one comment

http://codereview.chromium.org/9181002/diff/46001/content/public/browser/prof...
File content/public/browser/profiler_controller.h (right):

http://codereview.chromium.org/9181002/diff/46001/content/public/browser/prof...
content/public/browser/profiler_controller.h:47:
tracked_objects::ThreadData::Status status) = 0;
i think you'll want to have the header in this file, and not in the impl.h

[jar (doing other things), 2012-02-07 00:08:03]

Change per comment by jam@

http://codereview.chromium.org/9181002/diff/46001/content/public/browser/prof...
File content/public/browser/profiler_controller.h (right):

http://codereview.chromium.org/9181002/diff/46001/content/public/browser/prof...
content/public/browser/profiler_controller.h:47:
tracked_objects::ThreadData::Status status) = 0;
Good catch.  The "include what you use" rule says it should be in both.... so
I'll just add it here.

Thanks!

On 2012/02/06 23:44:07, John Abd-El-Malek wrote:
> i think you'll want to have the header in this file, and not in the impl.h