Implement frame attribution (FrameBlamer)

Implement frame attribution (FrameBlamer)

This patch implements two types of blame contexts:

1. A render frame blame context, which is used to attribute costs
   toward a particular web frame (i.e., a top-level frame or an iframe).

2. A render thread blame context, which is the target for accounting
   costs that do not neatly fit into a single web frame. Examples
   of this are garbage collection and "default" task queues which span
   the entire renderer.

Design doc:
https://docs.google.com/document/d/15BB-suCb9j-nFt55yCFJBJCGzLg2qUm3WaSOPb8APtI

BUG=546021
Committed: https://crrev.com/b4cce1b31ea37766c159762f1b45af7599f72d62
Cr-Commit-Position: refs/heads/master@{#384323}

[Sami, 2015-11-27 11:26:25]

Description was changed from

==========
FrameBlamer v2 WIP
==========

to

==========
FrameBlamer v2 WIP

BUG=546021
==========

[Sami, 2016-02-26 21:35:17]

FYI this needs some polish, but base::debug::BlameContext is what I had in mind
for making frame blaming a little more structured. Ben, I think it should fit
together with your browser side patch too.

[benjhayden, 2016-02-29 18:51:25]

On 2016/02/26 at 21:35:17, skyostil wrote:
> FYI this needs some polish, but base::debug::BlameContext is what I had in
mind for making frame blaming a little more structured. Ben, I think it should
fit together with your browser side patch too.

I generally try very hard to avoid bike-shedding, but I wonder if we can find a
less emotionally-loaded word than "blame"? Perhaps something like
TraceExecutionContext or TraceAccountingContext?

[Sami, 2016-02-29 19:28:59]

On 2016/02/29 18:51:25, benjhayden_chromium wrote:
> I generally try very hard to avoid bike-shedding, but I wonder if we can find
a
> less emotionally-loaded word than "blame"? Perhaps something like
> TraceExecutionContext or TraceAccountingContext?

I'd also like to think of a better name if possible. I don't think the name
should have anything to do with tracing, however, since I don't think the two
need to be fundamentally intertwined at this level -- especially if we want to
later expand this to a runtime system.

ExecutionContext as a name is a little too overleaded already.
AttributionContext might work, although it's a tad vague. More suggestions
welcome :)

[benjhayden, 2016-02-29 19:30:36]

benjhayden@chromium.org changed reviewers:
+ benjhayden@chromium.org

[benjhayden, 2016-02-29 19:30:37]

Still reviewing but it's lunch time. :-)

This is looking pretty neat!

Should my FrameTreeNode snapshots should point directly to your
RenderFrameBlameContexts instead of an intermediate RenderFrame object? I'll dig
into this more after lunch.

Should we check with Onion Soup to make sure this looks good to them?

https://codereview.chromium.org/1447563002/diff/480001/base/debug/blame_conte...
File base/debug/blame_context.h (right):

https://codereview.chromium.org/1447563002/diff/480001/base/debug/blame_conte...
base/debug/blame_context.h:30: template <const char* category, const char* name,
const char* scope>
It seems like this just requires subclasses and users like
RenderFrameBlameContext to repeat themselves a few times.
Why not just have users pass these into the constructor like
TraceScopedTrackableObject does?
Also, if BlameContext is not a template, then you won't need a separate base
class, iiuc.

https://codereview.chromium.org/1447563002/diff/480001/base/debug/blame_conte...
base/debug/blame_context.h:65: bool is_tracing = false;
Looks like most of this method could be moved into TraceScopedTrackableObject.
Devtools might not need some of these features, but it seems like it
conceptually belongs there. I can imagine non-BlameContext
TraceScopedTrackableObjects that would want to replicate it.

[Sami, 2016-02-29 20:20:31]

Thanks for digging into this -- sorry I haven't written any comments for the
interface yet :)

https://codereview.chromium.org/1447563002/diff/480001/base/debug/blame_conte...
File base/debug/blame_context.h (right):

https://codereview.chromium.org/1447563002/diff/480001/base/debug/blame_conte...
base/debug/blame_context.h:30: template <const char* category, const char* name,
const char* scope>
On 2016/02/29 19:30:37, benjhayden_chromium wrote:
> It seems like this just requires subclasses and users like
> RenderFrameBlameContext to repeat themselves a few times.
> Why not just have users pass these into the constructor like
> TraceScopedTrackableObject does?
> Also, if BlameContext is not a template, then you won't need a separate base
> class, iiuc.

I agree that this is a little weird but I don't see a better way of doing it
with our current infrastructure. The basic problem is that all trace events
(including enter/leave context) will initialize a static structure at the call
site that points to the trace category info data structure. The pointer is
atomically set up the first time the we encounter the trace event and cached for
all eternity.

The result of this is that a single TRACE_EVENT macro instantiation can only
ever be associated with single category. In other words, you can't pass in the
category string dynamically since it may have already been cached in the static
pointer.

The workaround for is to ensure every time we pass in a unique category string
to TRACE_EVENT, we generate a separate bit of code for that instance using a
template. TraceScopedTrackableObject also has this problem since it's only
templatized by the object type, not the category.

I guess we could simplify this a little by requiring you to only pass the
category string as a template (or hard coding it so that all blame contexts use
the same category), but I'm not sure if that's better or worse than this
version.

(Full credit to fady@ for figuring this out earlier.)

https://codereview.chromium.org/1447563002/diff/480001/base/debug/blame_conte...
base/debug/blame_context.h:65: bool is_tracing = false;
On 2016/02/29 19:30:37, benjhayden_chromium wrote:
> Looks like most of this method could be moved into TraceScopedTrackableObject.

Right, we could move it there. I think I'd still want to have the AsValueInto()
virtual here somehow so that subclasses can add more metadata to the snapshot.

> Devtools might not need some of these features, but it seems like it
> conceptually belongs there. I can imagine non-BlameContext
> TraceScopedTrackableObjects that would want to replicate it.

Agreed about TraceScopedTrackableObjects, but I'm not sure what the DevTools
connection is here?

[Sami, 2016-02-29 20:21:06]

+fady too.

[Fady Samuel, 2016-02-29 20:23:17]

fsamuel@chromium.org changed reviewers:
+ fsamuel@chromium.org

[Fady Samuel, 2016-02-29 20:23:19]

I think you got the wrong Fad(y|i). +fmeawad@. +nduca@ in CC for giggles. :P

[Sami, 2016-02-29 20:27:13]

skyostil@chromium.org changed reviewers:
- fsamuel@chromium.org

[Sami, 2016-02-29 20:27:14]

Sorry, autocomplete fail on my part :\

[Sami, 2016-02-29 23:55:01]

+kouhei@

[Sami, 2016-03-01 03:11:21]

Description was changed from

==========
FrameBlamer v2 WIP

BUG=546021
==========

to

==========
Implement frame attribution (FrameBlamer)

This patch introduces the concept of a blame context, which is
a logical entity to which we can attribute various types of costs
(e.g., CPU, network bandwidth, memory, etc.). It also implements
the frame blame context which is be used for tracking these costs
for a particular web frame.

BUG=546021
==========

[chiniforooshan, 2016-03-03 20:39:39]

chiniforooshan@chromium.org changed reviewers:
+ chiniforooshan@chromium.org

[chiniforooshan, 2016-03-03 20:39:41]

https://codereview.chromium.org/1447563002/diff/540001/components/scheduler/b...
File components/scheduler/base/task_queue.h (right):

https://codereview.chromium.org/1447563002/diff/540001/components/scheduler/b...
components/scheduler/base/task_queue.h:194: // Set the blame context for all
tasks executed from this queue.
Shouldn't this be SetBlameContexts (plural) (or AddBlameContext)? I thought a
task could potentially belong to several contexts, no?

[Sami, 2016-03-08 14:36:10]

https://codereview.chromium.org/1447563002/diff/540001/components/scheduler/b...
File components/scheduler/base/task_queue.h (right):

https://codereview.chromium.org/1447563002/diff/540001/components/scheduler/b...
components/scheduler/base/task_queue.h:194: // Set the blame context for all
tasks executed from this queue.
On 2016/03/03 20:39:41, chiniforooshan wrote:
> Shouldn't this be SetBlameContexts (plural) (or AddBlameContext)? I thought a
> task could potentially belong to several contexts, no?

I've limited a single task queue to only belonging to a single blame context for
simplicity. The tasks themselves can still enter any number of contexts, but we
only support entering one automatically for all tasks.

I've reworded this a bit to make it more obvious.

[Sami, 2016-03-08 15:14:05]

Description was changed from

==========
Implement frame attribution (FrameBlamer)

This patch introduces the concept of a blame context, which is
a logical entity to which we can attribute various types of costs
(e.g., CPU, network bandwidth, memory, etc.). It also implements
the frame blame context which is be used for tracking these costs
for a particular web frame.

BUG=546021
==========

to

==========
Implement frame attribution (FrameBlamer)

This patch implements two types of blame contexts:

1. A render frame blame context, which is used to attribute costs
   toward a particular web frame (i.e., a top-level frame or an iframe).

2. A render thread blame context, which is the target for accounting
   costs that do not neatly fit into a single web frame. Examples
   of this are garbage collection and "default" task queues which span
   the entire renderer.

Design doc:
https://docs.google.com/document/d/15BB-suCb9j-nFt55yCFJBJCGzLg2qUm3WaSOPb8APtI

BUG=546021
==========

[Sami, 2016-03-21 12:14:29]

Patchset #39 (id:760001) has been deleted

[Sami, 2016-03-21 12:23:04]

skyostil@chromium.org changed reviewers:
+ alexclarke@chromium.org

[Sami, 2016-03-21 12:25:19]

Okay, I think the base/ interface is now settling down. Ben, Ehsan, WDYT about
this one now?

Alex, could you take a gander at components/scheduler/?

[alex clarke (OOO till 29th), 2016-03-21 14:38:36]

scheduler/ LGTM

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/b...
File components/scheduler/base/task_queue.h (right):

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/b...
components/scheduler/base/task_queue.h:195: // this task queue. |blame_context|
must be null or outlive this task queue.
Please mention this is main thread only.

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/r...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:1141:
idle_helper_.IdleTaskRunner()->SetBlameContext(blame_context);
Maybe add a note that loading_task_runners_ and timer_task_runners_ are dealt
with separately.

https://codereview.chromium.org/1447563002/diff/800001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/page/ChromeClient.h (right):

https://codereview.chromium.org/1447563002/diff/800001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/ChromeClient.h:36: #include
"platform/TraceEvent.h"
nit: is this needed?

[Sami, 2016-03-21 15:18:05]

Thanks Alex, all addressed.

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/b...
File components/scheduler/base/task_queue.h (right):

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/b...
components/scheduler/base/task_queue.h:195: // this task queue. |blame_context|
must be null or outlive this task queue.
On 2016/03/21 14:38:36, alexclarke1 wrote:
> Please mention this is main thread only.

Done.

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/r...
File components/scheduler/renderer/renderer_scheduler_impl.cc (right):

https://codereview.chromium.org/1447563002/diff/800001/components/scheduler/r...
components/scheduler/renderer/renderer_scheduler_impl.cc:1141:
idle_helper_.IdleTaskRunner()->SetBlameContext(blame_context);
On 2016/03/21 14:38:36, alexclarke1 wrote:
> Maybe add a note that loading_task_runners_ and timer_task_runners_ are dealt
> with separately.

Done.

https://codereview.chromium.org/1447563002/diff/800001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/page/ChromeClient.h (right):

https://codereview.chromium.org/1447563002/diff/800001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/page/ChromeClient.h:36: #include
"platform/TraceEvent.h"
On 2016/03/21 14:38:36, alexclarke1 wrote:
> nit: is this needed?

Good catch, removed.

[benjhayden, 2016-03-21 17:32:57]

https://codereview.chromium.org/1447563002/diff/820001/components/scheduler/b...
File components/scheduler/base/time_domain.cc (right):

https://codereview.chromium.org/1447563002/diff/820001/components/scheduler/b...
components/scheduler/base/time_domain.cc:231: state->EndArray();
Looks like a bugfix for a separate CL?

https://codereview.chromium.org/1447563002/diff/820001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1447563002/diff/820001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1076: if (frame_->parent()) {
Maybe move this logic into RenderFrameBlameContext?

https://codereview.chromium.org/1447563002/diff/820001/content/renderer/rende...
content/renderer/render_frame_impl.cc:3256:
blame_context_->set_url(frame_->getSecurityOrigin().toString().utf8());
Could you make the RenderFrameBlameContext observe the RenderFrame instead?

https://codereview.chromium.org/1447563002/diff/820001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebViewImpl.h (right):

https://codereview.chromium.org/1447563002/diff/820001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebViewImpl.h:42: #include
"public/platform/Platform.h"
necessary?

[Sami, 2016-03-21 19:16:30]

https://codereview.chromium.org/1447563002/diff/820001/components/scheduler/b...
File components/scheduler/base/time_domain.cc (right):

https://codereview.chromium.org/1447563002/diff/820001/components/scheduler/b...
components/scheduler/base/time_domain.cc:231: state->EndArray();
On 2016/03/21 17:32:56, benjhayden_chromium wrote:
> Looks like a bugfix for a separate CL?

Done (landed separately).

https://codereview.chromium.org/1447563002/diff/820001/content/renderer/rende...
File content/renderer/render_frame_impl.cc (right):

https://codereview.chromium.org/1447563002/diff/820001/content/renderer/rende...
content/renderer/render_frame_impl.cc:1076: if (frame_->parent()) {
On 2016/03/21 17:32:56, benjhayden_chromium wrote:
> Maybe move this logic into RenderFrameBlameContext?

Good idea, done.

https://codereview.chromium.org/1447563002/diff/820001/content/renderer/rende...
content/renderer/render_frame_impl.cc:3256:
blame_context_->set_url(frame_->getSecurityOrigin().toString().utf8());
On 2016/03/21 17:32:56, benjhayden_chromium wrote:
> Could you make the RenderFrameBlameContext observe the RenderFrame instead?

Great idea, no need to add new explicit calls.

https://codereview.chromium.org/1447563002/diff/820001/third_party/WebKit/Sou...
File third_party/WebKit/Source/web/WebViewImpl.h (right):

https://codereview.chromium.org/1447563002/diff/820001/third_party/WebKit/Sou...
third_party/WebKit/Source/web/WebViewImpl.h:42: #include
"public/platform/Platform.h"
On 2016/03/21 17:32:56, benjhayden_chromium wrote:
> necessary?

Oops, removed.

[benjhayden, 2016-03-21 19:31:38]

lgtm, thanks!

[Sami, 2016-03-22 10:29:33]

skyostil@chromium.org changed reviewers:
+ jochen@chromium.org

[Sami, 2016-03-22 10:30:13]

Thanks Ben. Jochen, mind taking a look at content/ and third_party/WebKit?

[Sami, 2016-03-23 12:37:53]

Rebased

[jochen (gone - plz use gerrit), 2016-03-24 14:38:39]

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/BlameContext.h (right):

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
third_party/WebKit/public/platform/BlameContext.h:12: using BlameContext =
base::trace_event::BlameContext;
why not just use this directly? adding esprehn@ for input

[jochen (gone - plz use gerrit), 2016-03-24 14:38:58]

jochen@chromium.org changed reviewers:
+ esprehn@chromium.org

[jochen (gone - plz use gerrit), 2016-03-24 14:38:59]

+esprehn for realz. See my previous comment for the question

[esprehn, 2016-03-25 03:33:22]

RenderFrameBlameContext should be a blink API instead.

https://codereview.chromium.org/1447563002/diff/910001/content/renderer/rende...
File content/renderer/render_frame_blame_context.cc (right):

https://codereview.chromium.org/1447563002/diff/910001/content/renderer/rende...
content/renderer/render_frame_blame_context.cc:45: url_ =
render_frame()->GetWebFrame()->getSecurityOrigin().toString().utf8();
ouch, this is putting even more code in content. I'd rather we didn't do this.
Why is this not an API of blink?

https://codereview.chromium.org/1447563002/diff/910001/content/renderer/rende...
content/renderer/render_frame_blame_context.cc:52: state->SetString("url",
url_);
yeah this doesn't belong in content.

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/BlameContext.h (right):

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
third_party/WebKit/public/platform/BlameContext.h:12: using BlameContext =
base::trace_event::BlameContext;
On 2016/03/24 at 14:38:39, jochen - slow wrote:
> why not just use this directly? adding esprehn@ for input

base is not allowed in core/, it's a simple rule to enforce what's being used
where. Is the whole BlameContext API really for public use anywhere in blink?

[Sami, 2016-03-29 10:37:36]

Thanks for the comments Elliott.

> RenderFrameBlameContext should be a blink API instead.

That was one of the earlier approaches (see patch set #21[1]), but it ran into a
problem where Blink doesn't know the routing id for its frames, which is needed
for connecting the data from RenderFrameBlameContext into the browser side frame
tree.

I think there are basically three options:

1. Teach Blink about the routing id (or some equivalent frame identifier). We
had a thread about this with site-isolation-dev@ and others and the idea didn't
get much traction (e.g., Blink might end up trusting unvalidated routing ids by
mistake).

2. Introduce a bridge structure[2] in content that establishes the mapping
between routing id and whatever Blink uses. This feels like a kludge so I don't
like it.

3. Keep the FrameBlameContext in content/ which is what I've done in this patch.

Which solution would you suggest?

[1] https://codereview.chromium.org/1447563002/#ps400001
[2]
https://docs.google.com/drawings/d/1JXAVnsq_YCRauIieXJbtIMKKeWuREg99UccmZshl7...

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/BlameContext.h (right):

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
third_party/WebKit/public/platform/BlameContext.h:12: using BlameContext =
base::trace_event::BlameContext;
On 2016/03/25 03:33:22, esprehn wrote:
> On 2016/03/24 at 14:38:39, jochen - slow wrote:
> > why not just use this directly? adding esprehn@ for input
> 
> base is not allowed in core/, it's a simple rule to enforce what's being used
> where. Is the whole BlameContext API really for public use anywhere in blink?

It's ready, although I wouldn't expect that many client using it. The main ones
are in core/ where we want to annotate places where we descend into to different
frames (e.g., during rAF) or do global things (GC).

[Sami, 2016-03-30 13:44:32]

Elliott and I had a chat and concluded that having the blame context in content/
is fine for now but we should consider moving the blink specific scheduler
machinery over to blink to reduce some of the plumbing. Also, I've removed url
serialization since it's redundant with the browser frame tree and (hopefully)
improved the naming. PTAL.

[esprehn, 2016-03-31 00:47:04]

lgtm

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/Platform.h (right):

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
third_party/WebKit/public/platform/Platform.h:363: virtual BlameContext*
threadBlameContext() { return nullptr; }
can this get a better name? Platform is used by many threads.

[Sami, 2016-03-31 10:28:40]

Fix test failures

[Sami, 2016-03-31 10:29:49]

Thanks!

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
File third_party/WebKit/public/platform/Platform.h (right):

https://codereview.chromium.org/1447563002/diff/910001/third_party/WebKit/pub...
third_party/WebKit/public/platform/Platform.h:363: virtual BlameContext*
threadBlameContext() { return nullptr; }
On 2016/03/31 00:47:04, esprehn wrote:
> can this get a better name? Platform is used by many threads.

I've changed it to "topLevelBlameContext" with a more informative comment.

[Sami, 2016-03-31 10:30:00]

The CQ bit was checked by skyostil@chromium.org

[Sami, 2016-03-31 10:30:01]

The patchset sent to the CQ was uploaded after l-g-t-m from
alexclarke@chromium.org, benjhayden@chromium.org, esprehn@chromium.org
Link to the patchset: https://codereview.chromium.org/1447563002/#ps970001
(title: "Fix test failures")

[commit-bot: I haz the power, 2016-03-31 10:30:16]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1447563002/970001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1447563002/970001

[commit-bot: I haz the power, 2016-03-31 10:32:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-31 10:32:54]

Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Sami, 2016-03-31 10:58:50]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2016-03-31 10:59:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1447563002/970001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1447563002/970001

[commit-bot: I haz the power, 2016-03-31 11:28:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-31 11:28:54]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Sami, 2016-03-31 15:13:19]

Make sure blame context is initialized early enough

[Sami, 2016-03-31 15:17:07]

The CQ bit was checked by skyostil@chromium.org

[Sami, 2016-03-31 15:17:08]

The patchset sent to the CQ was uploaded after l-g-t-m from
esprehn@chromium.org, benjhayden@chromium.org, alexclarke@chromium.org
Link to the patchset: https://codereview.chromium.org/1447563002/#ps990001
(title: "Make sure blame context is initialized early enough")

[commit-bot: I haz the power, 2016-03-31 15:17:30]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1447563002/990001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1447563002/990001

[commit-bot: I haz the power, 2016-03-31 15:59:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-03-31 15:59:52]

Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Sami, 2016-03-31 17:05:48]

The CQ bit was checked by skyostil@chromium.org

[commit-bot: I haz the power, 2016-03-31 17:06:04]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1447563002/990001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1447563002/990001

[commit-bot: I haz the power, 2016-03-31 17:56:45]

Description was changed from

==========
Implement frame attribution (FrameBlamer)

This patch implements two types of blame contexts:

1. A render frame blame context, which is used to attribute costs
   toward a particular web frame (i.e., a top-level frame or an iframe).

2. A render thread blame context, which is the target for accounting
   costs that do not neatly fit into a single web frame. Examples
   of this are garbage collection and "default" task queues which span
   the entire renderer.

Design doc:
https://docs.google.com/document/d/15BB-suCb9j-nFt55yCFJBJCGzLg2qUm3WaSOPb8APtI

BUG=546021
==========

to

==========
Implement frame attribution (FrameBlamer)

This patch implements two types of blame contexts:

1. A render frame blame context, which is used to attribute costs
   toward a particular web frame (i.e., a top-level frame or an iframe).

2. A render thread blame context, which is the target for accounting
   costs that do not neatly fit into a single web frame. Examples
   of this are garbage collection and "default" task queues which span
   the entire renderer.

Design doc:
https://docs.google.com/document/d/15BB-suCb9j-nFt55yCFJBJCGzLg2qUm3WaSOPb8APtI

BUG=546021
==========

[commit-bot: I haz the power, 2016-03-31 17:56:50]

Committed patchset #50 (id:990001)

[commit-bot: I haz the power, 2016-03-31 17:59:45]

Description was changed from

==========
Implement frame attribution (FrameBlamer)

This patch implements two types of blame contexts:

1. A render frame blame context, which is used to attribute costs
   toward a particular web frame (i.e., a top-level frame or an iframe).

2. A render thread blame context, which is the target for accounting
   costs that do not neatly fit into a single web frame. Examples
   of this are garbage collection and "default" task queues which span
   the entire renderer.

Design doc:
https://docs.google.com/document/d/15BB-suCb9j-nFt55yCFJBJCGzLg2qUm3WaSOPb8APtI

BUG=546021
==========

to

==========
Implement frame attribution (FrameBlamer)

This patch implements two types of blame contexts:

1. A render frame blame context, which is used to attribute costs
   toward a particular web frame (i.e., a top-level frame or an iframe).

2. A render thread blame context, which is the target for accounting
   costs that do not neatly fit into a single web frame. Examples
   of this are garbage collection and "default" task queues which span
   the entire renderer.

Design doc:
https://docs.google.com/document/d/15BB-suCb9j-nFt55yCFJBJCGzLg2qUm3WaSOPb8APtI

BUG=546021

Committed: https://crrev.com/b4cce1b31ea37766c159762f1b45af7599f72d62
Cr-Commit-Position: refs/heads/master@{#384323}
==========

[commit-bot: I haz the power, 2016-03-31 17:59:47]

Patchset 50 (id:??) landed as
https://crrev.com/b4cce1b31ea37766c159762f1b45af7599f72d62
Cr-Commit-Position: refs/heads/master@{#384323}