Memory profiling in chrome://tracing

[Primiano Tucci]

[bcc: blink-dev]

Hi there!

Short version

• A first preview of memory profiling in chrome://tracing has landed today, try it out, file bugs.
• Instructions, example, design docs on the chromium.org wiki page (TL;DR: open chrome://tracing, tick memory-infra, profit).
• Overview, updates and plans in this mail.
• Have a nice weekend!

What is memory-infra? Where is it going?

Memory-infra (aka memory in chrome://tracing) is a project aimed at tooling / infrastructure for memory profiling of Chrome via chrome://tracing. It concretely consists of both instrumentation in the chromium codebase and analysis/UI in TraceViewer.

It works essentially in two dimensions: time and depth.

time: timeline-based measurements

• What happened on the timeline while we saw a memory increase?
• Was that a cc::draw() on the timeline, or a HTMLDocumentParser::processParsedChunk() ?

depth: details coming from various instrumented memory subsystems 

• +X MiB were allocated during Event Y. Where did they go? jit-ted code in V8? some rendering partition in PartAlloc? Somewhere in the font cache? 
  
• I opened about:blank, renderer memory is X MiB, navigate to example.com memory is X + 100 MiB, navigate back to about blank, memory is X + 20 MiB. What are those +20 MiB left around? Where did they go? Where are they hiding?

Well, we might not have an answers to all these questions today, but this is where this is shooting at. Take a look to the wiki for more

Today in master

time: dump every 250 ms. Not great, we can do better, but it's the best tradeoff we could get to begin with. 

depth: total resident/pss numbers, full breakdown of mapped files/libraries on Linux/Android, dumpers for v8, PartAlloc, discardable memory, some of the many GPU buffers.

Upcoming work

time: make the memory tracing dynamically triggerable. E.g., dump every X ms as a baseline AND upon all occurrences of FooBar tasks (my previous investigations made me very suspicious about FooBar, I want to see more on that)

depth: there is a large list of subsystems we need to instrument to get more horizontal coverage. 

UI: we have loads of data, even today. We need to present that in a legible and actionable way. Lot of room for improvements here.

Automation / C.I.: on a parallel track we are working to get all these memory metrics part of telemetry, pushed to the chromeperf dasbhoard, so we'll be able to plot the {evolution of the  various subsystems} x {each benchmark} x {range of revisions}

 

See the FAQ section in the wiki page for more.

Vision

Memory bloat in Chrome should be dealt with in the same way of crashes:

• The lower the better.
• A crash is an individual responsibility of each developer. If you cause a crash you should fix that (but you need a debugger to see and reproduce that).
• Crashes are hard to fix but easy to spot. When Chrome crashes, you look at top frames of the stack trace in your log and say "aha" this crashed in xxx::yyyy(), you file a bug and triage to the right person / team. 
• You want a debugger which speaks Chrome slang. If you see a bunch of obscure numbers / addresses you can't really do that much, other than realizing that chrome crashed. You want to see v8:: blink:: content::, etc.

Now, go up to the top of the list and s/crash/memory bloat/, s/is/should become/  :)

Regards,

Primiano

On behalf of

perezju@ (automate all the things)

petrcermak@ (visualize all the things)

ssid@ (instrument all the things)