Stop using the TRACE_EVENT_*_ETW macros.

Stop using the TRACE_EVENT_*_ETW macros.

All tracing macros can now export events to ETW (see
TraceEventETWExport). Therefore, there is no reason to keep using the
old TRACE_EVENT_*_ETW macros.

The tracing infrastructure doesn't expect synchronous events around
the main loop of a thread. For this reason, the TRACE_EVENT_*_ETW
macros have been replaced by TRACE_EVENT_ASYNC_* macros instead of
simple TRACE_EVENT* macros in some cases.

Once this patch has landed, the TRACE_EVENT_*ETW macros will be
removed (https://codereview.chromium.org/1376793004/)

BUG=#1263
BUG=489720
Committed: https://crrev.com/f6d86240c1fcab19d205d6531c860cda02bf537a
Cr-Commit-Position: refs/heads/master@{#353076}

[fdoray, 2015-10-06 19:41:18]

fdoray@chromium.org changed reviewers:
+ beaudoin@chromium.org, cpu@chromium.org, nduca@chromium.org

[fdoray, 2015-10-06 19:41:18]

Could you review this CL? Thanks.

[cpu_(ooo_6.6-7.5), 2015-10-06 20:18:30]

cpu@chromium.org changed reviewers:
+ brucedawson@chromium.org

[cpu_(ooo_6.6-7.5), 2015-10-06 20:18:30]

I can rubberstamp, but I let bruce do the actual review.

[beaudoin, 2015-10-06 20:57:38]

https://codereview.chromium.org/1386193002/diff/1/content/browser/browser_mai...
File content/browser/browser_main.cc (right):

https://codereview.chromium.org/1386193002/diff/1/content/browser/browser_mai...
content/browser/browser_main.cc:33: TRACE_EVENT_ASYNC_END0("startup",
"BrowserMain", 0);
There's a "return" a couple of lines above that will "leak" this async event. I
get it was like that before but maybe we should fix it now?

[brucedawson, 2015-10-07 00:42:57]

While it is true that all tracing events can be emitted as ETW events, this is
not universally true in an ideal way. There is a set of a dozen or so categories
(see kFilteredEventGroupNames) that can be individually requested. The other
categories have to be requested as a large (cumbersome) group.

Many of the new tracing events in this change use the startup category which is
not one of the privileged groups. To allow ETW tracing of them we should add
"startup" to kFilteredEventGroupNames, presumably with value 0x4000. Just adding
to the end of the array is sufficient on the Chrome side. I can then add a
corresponding entry to UIforETW so that it can easily request that category.

https://codereview.chromium.org/1386193002/diff/1/content/browser/browser_mai...
File content/browser/browser_main.cc (right):

https://codereview.chromium.org/1386193002/diff/1/content/browser/browser_mai...
content/browser/browser_main.cc:33: TRACE_EVENT_ASYNC_END0("startup",
"BrowserMain", 0);
On 2015/10/06 20:57:38, beaudoin wrote:
> There's a "return" a couple of lines above that will "leak" this async event.
I
> get it was like that before but maybe we should fix it now?

Seems worth fixing.

[fdoray, 2015-10-07 15:46:49]

Could you take another look? Thanks.

I added "startup" to kFilteredEventGroupNames as recommended by brucedawson@.

https://codereview.chromium.org/1386193002/diff/1/content/browser/browser_mai...
File content/browser/browser_main.cc (right):

https://codereview.chromium.org/1386193002/diff/1/content/browser/browser_mai...
content/browser/browser_main.cc:33: TRACE_EVENT_ASYNC_END0("startup",
"BrowserMain", 0);
On 2015/10/07 00:42:56, brucedawson wrote:
> On 2015/10/06 20:57:38, beaudoin wrote:
> > There's a "return" a couple of lines above that will "leak" this async
event.
> I
> > get it was like that before but maybe we should fix it now?
> 
> Seems worth fixing.

Done.

[brucedawson, 2015-10-07 19:04:23]

One question, but lgtm.

https://codereview.chromium.org/1386193002/diff/40001/content/renderer/render...
File content/renderer/render_thread_impl.cc (left):

https://codereview.chromium.org/1386193002/diff/40001/content/renderer/render...
content/renderer/render_thread_impl.cc:765:
TRACE_EVENT_END_ETW("RenderThreadImpl::Init", 0, "");
Why is this call being removed completely?

[cpu_(ooo_6.6-7.5), 2015-10-07 20:26:57]

lgtm on my side.

[fdoray, 2015-10-08 15:38:27]

https://codereview.chromium.org/1386193002/diff/40001/content/renderer/render...
File content/renderer/render_thread_impl.cc (left):

https://codereview.chromium.org/1386193002/diff/40001/content/renderer/render...
content/renderer/render_thread_impl.cc:765:
TRACE_EVENT_END_ETW("RenderThreadImpl::Init", 0, "");
On 2015/10/07 19:04:23, brucedawson wrote:
> Why is this call being removed completely?

TRACE_EVENT0 emits a synchronous event with a start and end time. The end time
is taken at the end of the scope that contains the TRACE_EVENT0 macro. We don't
need and end event here, because we will get the end time of "RenderThreadImpl"
from the event emitted by TRACE_EVENT0.

At other places in this CL, I didn't use TRACE_EVENT0 because the tracing
infrastructure doesn't expect synchronous events around the main loop of a
thread. Here, it's ok to use TRACE_EVENT0 because we are not around a message
loop.

[fdoray, 2015-10-08 15:39:27]

The CQ bit was checked by fdoray@chromium.org

[commit-bot: I haz the power, 2015-10-08 15:41:16]

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

[commit-bot: I haz the power, 2015-10-08 16:50:04]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2015-10-08 16:50:44]

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