Add process lifetime annotations to stack samples.

components/metrics/proto/execution_context.proto

 // Copyright 2016 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 syntax = "proto2";
 
 option optimize_for = LITE_RUNTIME;
 option java_outer_classname = "ExecutionContextProtos";
 option java_package = "org.chromium.components.metrics";
 
@@ skipping 29 matching lines @@
   IO_THREAD = 6;
   DB_THREAD = 7;
 
   // GPU process thread.
   GPU_MAIN_THREAD = 8;
 
   // Renderer process threads.
   RENDER_THREAD = 9;
   UTILITY_THREAD = 10;
 }
+
+// Process phases, or where in the lifetime of the process it is such as
+// startup, normal operation, shutdown, etc. These don't necessarily occur in
+// the order defined here so it's fine to add new ones to further segregrate
+// the lifetime of a process.
+enum ProcessPhase {
+  MAIN_LOOP_STARTED = 0;
+  FIRST_NON_EMPTY_PAINT = 1;
+}
+
+// Process activities. These are actions that start and end, likely many
+// times, throughout the lifetime of a process.
+enum ProcessActivity {
+  METRICS_COLLECTION = 0;

[Mike Wittman, 2016/11/02 21:44:04]

What's the rationale beyond recording metrics collection as a phase?

[bcwhite, 2016/11/03 18:29:50]

It's not a phase, just a periodic activity that occurs (begins and ends) during
normal operation.  It's not yet used and so could change if it's not useful but
there has to be at least one value defined for tests not to break.

[Mike Wittman, 2016/11/03 21:15:39]

Sorry, "phase" was a typo. So, three things:

1. Proto changes have to be reviewed in google3 by internal logging and privacy
teams, and committed before they can be approved for commit in the Chrome
repository.

2. There's a substantial cost to changing these enums, both in terms of
re-review and backwards compatibility. Once sent over the wire the enum values
essentially have to live forever so the data can continue to be interpreted
server-side.

3. As a result, we should settle on exactly what these enums need to contain to
support recording the desired startup information, and get that reviewed in
google3 before committing here. If we don't have a need for recording process
activity yet then it should be removed for the time being.

[bcwhite, 2016/11/03 21:51:10]

Ah, well then.  I had planned to get this in, then the follow-on CL, all before
going the google3 version.  Since nothing yet sets those bits, they could be
changed to whatever with no backward compatibility problems.

I guess there will have to be some discussion next week.

[Mike Wittman, 2016/11/03 23:11:03]

In general we shouldn't be committing Chrome functionality to support uploading
new state -- even if incomplete or disabled -- until we have policy approval for
saving the state. There are too many things that could go wrong (e.g. random bit
flips) that could cause state to be uploaded anyway and put us in questionable
territory. Google3 approval for this stuff, once settled, shouldn't be difficult
or take very long.

Let's move discussions of which startup phases should be recorded into the bug.

I won't be there for discussions next week, but I'm sure Alexei can provide
guidance.

[bcwhite, 2016/11/04 14:03:45]

Makes perfect sense.  I just didn't know about it.

+}