New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 681079 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
ssid@chromium.org
█ mariakho...@chromium.org
erikc...@chromium.org
█ dskiba@chromium.org
█ picksi@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

memory-infra heap profiler: enable only for a specific process

Project Member Reported by primiano@chromium.org, Jan 13 2017 
Background context: go/memory-infra

Follow up to the offline discussion today. The question is: should we have something in the trace config to say "enable heap profiler only on this(these) process(es)".
There are two aspects here:
1) --enable-heap-profiling we can't do anything here, as this happens very early, so all processes must do the heap tracking. I think this is very hard to change. At the same time, this doesn't cause too many problems % slowdown.
2) the actual dump in the trace. this is what might cause problems. If we have 50 renderers and all them dump their heap, the trace explodes.

Having the filter in the trace config would solve 2

Comment 1 by dskiba@chromium.org, Jan 13 2017 

What if we had a UI for memory dumps where it would show all processes, with two options: 

1. Take a Heap Dump from selected processes (and add it to the current trace file)
2. Save current trace file do disk

I.e. the idea is to have special memory-infra UI for taking memory dumps. We can start with something simple, and then gradually improve it.

Comment 2 by primiano@chromium.org, Jan 16 2017 

2 is already supported by go/traceontap (that I should remember to check in, I have a pending codereview)
1 I think the best way here is to introduce a level of the form "DETAILED_FOR_PROCESS" in MemoryDumpREquestArgs and propagate the change to the devtools protocol, so we can add the following feature to trace-on-tap:
 - Enable tracing (this is already possible via devtools)
 - request dump with "DETAILED_FOR_PROCESS". RequestMemoryDump is already exposed in the devtools protocol, however only when binding to the browser process. An extension can only bind to the renderer process and from there we don't propagate the call. It's a matter of finish that part of the plumbing in devtools.
 - disable tracing (already possible)
►

Sign in to add a comment