I did it this way because I didn't want to worry about "custom" process types but I see now that it'll be confusing should new standard types get added because the numeric value of the added type will duplicate the number currently used for the custom processes.  I either didn't realize or didn't think about the "overflow" bucket.

I think the better choice is to put "if (type < PROCESS_TYPE_CONTENT_END)" around the histogram and so avoid this if new process types get added in the future.

It could be made "sparse" but the new single-value optimization makes it pretty much the same thing.

The sparse suggestion is not for optimizing memory use but so we don't have to specify a max value.

I think we should aim for the same functionality for all the processes - that means if we're currently missing some processes (in Chrome - not talking about other products built from Chrome codebase) that are implemented outside of content/ and thus use a value above PROCDESS_TYPE_CONTENT_END then we should figure out what they are and add support for them.

Understood but there's a big problem that new process types would be injected in the middle of the extended enum.  I think it's simpler and safer to cap the reporting at the standard types to that any new values in the future will get reported without conflict.

Well, there will be technically be conflict but I think we can safely assume that the existing values will have expired long before a new process type gets added.

Sorry, I'm not following.

"there's a big problem that new process types would be injected in the middle of the extended enum"

Why is this a problem? Sparse histograms definitely support non-contiguous enums so I don't think there should be any issues here.

"I think it's simpler and safer to cap the reporting at the standard types to that any new values in the future will get reported without conflict."

Well, this ignored the fact that we're missing some process types *today* in shipping Chrome. The histogram can help us find those and add support for them.

It's not the continuity but the meaning.  We could have a bunch of counts for untracked process #12 and be okay with that because they're not standard processes.  It's in that "custom" process range.

Then someone adds a new standard process that, because items are added to the middle of the enum, becomes #12.  It's stats are untracked but we don't notice because there have always been counts for #12.

So I think it's better to report "untracked" for only standard process types and not the custom ones.

At which point, since there will generally be no counts and the adding of a new (untracked) process would add only add one count, there's no benefit of sparse of linear.

Perhaps we can still log it sparse but for custom processes, add a large base offset (e.g. 1000 - instead of the PROCESS_TYPE_CONTENT_END base) so there's no chance of a future standard process colliding with a previous custom one?

My ultimate point is we should figure out which process this is and support it as well for persistent metrics. The logging is only an issue because it currently doesn't help us with "figure out which process this is".

Do we know if any method of metrics are supported for these custom processes?

If you want to be concerned with custom processes, then sure.  My feeling is that we should just ignore anything that isn't officially listed in the enumeration.

No, I don't know. I guess I'd like us to first find out what they are before deciding whether we should ignore them or not. And we need the histogram to find out what they are.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c600ac1d2771eb57c0875a0a9fe6002238eb89fc

commit c600ac1d2771eb57c0875a0a9fe6002238eb89fc
Author: bcwhite <bcwhite@chromium.org>
Date: Wed Jul 12 13:37:13 2017

Don't report 'custom' processes as untracked.

BUG= 728322 

Review-Url: https://codereview.chromium.org/2967063002
Cr-Commit-Position: refs/heads/master@{#485936}

[modify] https://crrev.com/c600ac1d2771eb57c0875a0a9fe6002238eb89fc/content/browser/browser_child_process_host_impl.cc
[modify] https://crrev.com/c600ac1d2771eb57c0875a0a9fe6002238eb89fc/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/c600ac1d2771eb57c0875a0a9fe6002238eb89fc/tools/metrics/histograms/histograms.xml