Add a histogram for renderer memory usage.

Add a histogram for renderer memory usage.

The difference to Renderer.Memory are:
- we're looking at the memory held by our allocator, and not what the system reports
- we're sampling not only once an hour, but much more often
- we're going through the HistogramCustomizer

BUG=160979

[jochen (gone - plz use gerrit), 2012-11-12 15:45:25]

plz review

Jim, the overall histogram usage

Charlie, owners approval

[jar (doing other things), 2012-11-12 20:36:43]

The use of the histograms LGTM (safe and correct).

I'm a bit wary of what the data will show.  Have you tried this on your personal
machine (looking about about:histograms)?  What is it you see (or don't see)?

[jochen (gone - plz use gerrit), 2012-11-12 20:45:28]

On 2012/11/12 20:36:43, jar wrote:
> The use of the histograms LGTM (safe and correct).
> 
> I'm a bit wary of what the data will show.  Have you tried this on your
personal
> machine (looking about about:histograms)?  What is it you see (or don't see)?

So far, I've verified that the data is send to the correct histogram based on
what URL is displayed. Since I didn't run the browser for a long time, I only
got some samples, but they looked reasonable.

What are you worried about? Or should I run some specific tests?

[jar (doing other things), 2012-11-12 20:53:02]

Sampling memory is always a strange game.  

You'll get lots of samples.... and the interesting question is what will it
show?  It will probably tend to show the distribution of memory used.... but it
will have a strong bias towards the folks that keep a renderer going for a long
time.  For instance, folks with background tabs might(?) get to put in a lot of
samples.  

I'm not clear on how to normalized it, and what it will mean.  For instance,
folks that crash tabs will get a fresh start.  Hence if we crash a lot of tabs,
we might lower the stats :-/.  It may also be that when a tab has a lot of
memory, then it will slow down(?), and that might drive a user to do something,
like close the tab, or shift-reload.  

I don't have a good way of normalizing any of this... or of seeing impact of
other items..... but we'll see what we see ;-).

On 2012/11/12 20:45:28, jochen wrote:
> On 2012/11/12 20:36:43, jar wrote:
> > The use of the histograms LGTM (safe and correct).
> > 
> > I'm a bit wary of what the data will show.  Have you tried this on your
> personal
> > machine (looking about about:histograms)?  What is it you see (or don't
see)?
> 
> So far, I've verified that the data is send to the correct histogram based on
> what URL is displayed. Since I didn't run the browser for a long time, I only
> got some samples, but they looked reasonable.
> 
> What are you worried about? Or should I run some specific tests?

[Charlie Reis, 2012-11-13 02:41:36]

Rubber stamp LGTM for OWNERs, but I echo a bit of Jim's concern.  This data will
obviously be per-process and not per-tab, and it won't be possible to
distinguish between one heavy tab and a bunch of light tabs.

What's the intended use for the data?  Should there be a bug on file to describe
the motivation?

[jochen (gone - plz use gerrit), 2012-11-14 15:14:52]

I've created crbug.com/160979, wdyt?

[jar (doing other things), 2012-12-18 23:03:40]

Using the message_loop task observer can be expensive.  It is per-task, and it
used a thread-safe observer.  When I single stepped through it, the mere
presence of a non-empty list caused (as I recall) several lock acquisitions and
releases, as well as a few allocations and dellocations.  It was very impressive
:-/.  Truth is, I spotted we were doing this when the list was empty(!?!?!), and
fixed that, but once you populate the list, I can't avoid the problems :-/.

The jankometer (which used this) tended to be flag controlled, so it had no
generic perf impact.

Is this histogram sampling controlled by a flag, and not done in general? Is
this use of task observer new, or old?

You can also get away with a bunch of stats via about:profiler, and that is much
lower cost (and much more detailed).... but not currently gathered in all UMA
uploads, and not yet visualized via logs extraction :-/.