Not high prio but worth spending some time discussing this.

Today in the memory-infra heap profiler we took the decision of "start it form T=0 or bust". In other way there is no way to enable the heap profiler after chrome has started.
There is a very strong motivation for doing this: this is the only thing that guarantees a sensible view of the heap which can be reasoned about. In other words, we need to see all the allocations from the start to be able to explain all the bytes that are currently lying around.

Recently, however, some new use cases emerged. Sometimes we run into cases where a process grows and grows. In these cases my theory is that we don't actually care about having a coherent view of the heap (say, how much memory is due to cc, vs v8, vs blink etc). We just are in a state where something is exploding and is keeping allocating memory and we desperately want to find out what it is. In these cases it might be fine to start with an "unknown" state, e.g., "we started monitoring when chrome was using 2GB and, sorry, it's too late to say why" but we could still get the data about allocations that will happen in the future.

From a technical viewpoint, it shouldn't be too complicated. On top of my head, this is what we need:

- Exposing the EnableHeapProfiler() in the tracing endpoint of devtools API, so we can enable through an extension (say, TraceOnTap)
see https://chromedevtools.github.io/debugger-protocol-viewer/tot/Tracing/

- We really need to be careful and think what would happen in chrome when slow reports is enabled, hence tracing is enabled in recording mode. I have not idea what would happen in that case if we add the filtering mode on top while that happens (might be still fine as this would be purely triggered by human intervention, e.g. TraceOnTap)

- In TraceViewer, we need a clear message that says "you are looking at a partial/inconsistent state of the heap"