So if we do this, I think this should be a tri-state element:
1. disabled (default)
2. enabled (but requires manual tracing to get the snapshots)
3. enabled + auto-uploads: this will automatically grab snapshots and upload them somewhere.

Or maybe 3 should be the combination of  2 + having enabled deep reports ("navigation tracing")

From duplicate 689639 (by erikchen@):

"
Let's add a flag to about://flags that enables heap profiling [in the future, we can consider how to get native heap profiling, ajwong has some interesting ideas]. The flag should also allow us to collect dumps from the users, let's say at most by giving them a single button to press [trace on tap], or perhaps automatically uploaded [there may be privacy issues?] 

Then we can ask some people who we know have memory issues to turn on this flag, and we can start getting some live reports. 

cc-ing some people who are interested in this general sort of thing, and may have slightly different ideas on how we should do this.
"

 Issue 689639  has been merged into this issue.

I think the idea for now is to upload these reports as "deep reports". I don't know if there is "deep reports" dashboard though.

There is no pipeline for extracting memory data from deep reports. I believe they just get stored (in crash?), but we don't run any jobs on them to parse out the numbers from the traces.

Hmm, I wonder if the third option should be "enable slow reports". I.e. instead of heap profiling we would enable slow reports triggered by memory peaks.

The difference with "normal" slow reports is that this will be opt-in, and could be enabled on any build (even release one).

Re #9: NACK. that won't help with "malloc size is growing and we don't know why" which seems to happen more and more frequently. 
If we don't sort 3 out is not the end of the world, we can ask people to press a button in the meantime.

Check navigation_tracing.cc for the background tracing config which gets enabled for Deep Reports (i.e. the about://flags opt-in full-detail variant of Slow Reports). There's already a V8.GCLowMemoryNotification trigger present there, which can be modified or added to if we want to get reports from the existing Deep Reports population, or the same kind of background tracing setup could be used for a separate opt-in flag.

Other than the mechanism for enabling these reports, the rest of the pipeline is identical to the one ssid@ already made a memory-infra dashboard for, so the parsing/dashboard part should be easy enough.

That's all assuming you want automatic reporting and not a "submit trace plx" button, of course.

Re 10: If press a button and upload is the solution here then we do not need deep reports pipeline and processing. There will be very limited number of traces and can be looked at manually by the "memory sheriff" that we will have?

If we are doing auto upload then we can use deep reports. Yes, if we have large number of traces we can process them with the same pipeline. Currently I select only slow reports traces in processing for the dashboard. I can include option for deep reports traces if needed.

> Re 10: If press a button and upload is the solution here then we do not need deep reports pipeline and processing. There will be very limited number of traces and can be looked at manually by the "memory sheriff" that we will have?
Yup, for that I think that is a viable strategy and will fall into the Performance=Memory bug triaging process.

Auto-upload: let's discuss this in the "heap-profiling from the field document" as this has a broader scope and is off-topic for this bug.
This bug is about the fact that on some platforms the cmdline is not easily tweakable.
My fault having mis-driven the discussion when I wrote "3. enabled + auto-uploads". Forget about that point in this bug.
Let's use this to track the work for chrome://flags

No, it's not your fault, primiano@ :)

I think we initially treated both problems (enabling heap profiling / collecting results) as one.

And it makes sense to have just place to toggle all this.

And I also merged 689639 here, which was explicitly named "Turn on heap profiling in about://flags and enable collection of reports from users".

I agree that we should start by simply adding enabling-heap-profiling, but the issue doesn't stop there.

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

commit c6376a644a8db12cb1deebe497db1f390be8d11e
Author: dskiba <dskiba@chromium.org>
Date: Mon May 01 22:43:29 2017

[tracing] Allow enabling heap profiling from chrome://flags

BUG= 684839 

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

[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/base/base_switches.cc
[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/base/base_switches.h
[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/base/trace_event/memory_dump_manager.cc
[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/chrome/browser/about_flags.cc
[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/c6376a644a8db12cb1deebe497db1f390be8d11e/tools/metrics/histograms/histograms.xml