Memory-infra current state and plans

TRIM Conference - Nov 2016

What we have today

Memory-infra codebase in a nutshell

Probes in the codebase

• Oilpan Heap (most blink heap)
• PartitionAlloc (rest of blink heap)
• Discardable memory subsystem
• Compositor resources
• GPU buffers
• Skia caches
• IndexedDB resources
• LevelDB resources
• SQLite resources
• V8 heaps and zones
• VPX video decoder memory pools
• WebCache
• Android Runtime Heap

Memory-infra codebase in a nutshell

Probes in the codebase

• Oilpan Heap (most blink heap)
• PartitionAlloc (rest of blink heap)
• Discardable memory subsystem
• Compositor resources
• GPU buffers
• Skia caches
• IndexedDB resources
• LevelDB resources
• SQLite resources
• V8 heaps and zones
• VPX video decoder memory pools
• WebCache
• Android Runtime Heap

Memory-infra probes

All over the codebase

chrome://tracing

telemetry

Slow reports

Memory-infra codebase in a nutshell

Probes in the codebase

• Oilpan Heap (most blink heap)
• PartitionAlloc (rest of blink heap)
• Discardable memory subsystem
• Compositor resources
• GPU buffers
• Skia caches
• IndexedDB resources
• LevelDB resources
• SQLite resources
• V8 heaps and zones
• VPX video decoder memory pools
• WebCache
• Android Runtime Heap

Heap Profiler

• Discover the “dark matter”�(things for which we don’t have probes yet)
• Light version: just works ™ on on production out of the box on Linux/Android/Win/CrOS. Uses pseudo stack coming from trace events
• Heavy version: fine grained details (Linux/Android) using debugging symbols. Uses real stacks coming from stack unwinding

​

​

Heap Profiler

Instructions: https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/memory/heap-profiling-with-memory-infra

30.2 MiB

27.6

MiB

What’s next

Tracing Refactoring (Q3-Q4 16)

1. bit.ly/tracing-unbundling

Allow reusing tracing in standalone projects

Stop maintaining N forked copied of tracing (webrtc, skia, v8)

Unblock 2 below

​

• bit.ly/TracingV2 -> Tracing buffer proto-based

Stop OOM-ing when capturing big traces

Solve memory estimation problems

Moar data, smaller traces

Long tail of future improvements (don’t lose traces when navigating)

Memory-Infra UMA (Q1 17)

Today memory-infra is strongly coupled with tracing.

Good for debugging and telemetry, but still detached from UMA metrics.

​

What if

We could reuse the existing background-mode probes (the ones used by slow-reports) and use them to drive UMA?

​

Challenges:

1. Related metrics
2. When do we sample?

Peak detection

Today memory-infra dumps only:

• periodically, when using tracing
• Triggered by telemetry, in benchmarks
• Triggered by memory-pressure signals in slow-reports

​

Idea:

• Poll os counters, detect peak situations
• Create a dump when a peak is detected
• Same metric shared by telemetry, slow-reports and UMA

Heap Profiler from the field

We are reaching good understanding of labs scenarios.

​

Need more understanding of the longtail from users.

​

Not convinced by statistical sampling approaches.

​

Want a full heap dump when chrome gets into awkward situations.

What was the content of the heap when the browser/renderer heap was 4 GB?

Memory-infra & benchmarks

TRIM Conference - Nov 2016

Current memory benchmarks

Memory.top_10_mobile: historical reasons, FG/BG, is going away.

System_health.memory_{mobile,desktop}

• Loading stories: wait for page load, force gc (!), grab a mem snapshot
• Browsing stories: load, scroll/login/click, force gc(!), grab a snapshot
• Background stories: push the browser to bg, check memory in idle
• Long running stories: ~2 min
• Loading stories going away in favor of snapshots triggered by chrome events�(more later)

How do they look like on the dashboard?

Snapshots triggered by chrome events

Today memory benchmarks are fully driven by telemetry. Telemetry decides when to dump.

​

It’s a problem as it requires duplicating loading vs browsing stories.

​

Breaks the mental model of TBMv2 where a metric should be agnostic of the source of the trace (telemetry vs. field)

​

What’s going to change? What if:

• we inject triggers in the codebase: when memory-infra is enabled grab a snapshot on: (page-load, GC, peak detection)
• Create a metric for each event. Reuse the same metrics from the field.

​

Would this be enough to unify other benchmarks (e.g. v8) with sys health ones?

~200 metrics

(it is less scary than what it seems)

​

For each (device, page)

Browser_process

Renderer_processes

Gpu_process

All_processes (Σ)

Reported_by_os�(totals from system probes)�

Reported_by_chrome

(probes in the codebase)

system_memory

gpu_memory

private_dirty

Proportional resident

cc

V8

skia

...

gpu

blinkgc

webcache

...

New memory dashboard UI upcoming

DEMO hjd’s frontend

DEMO perezju’s dashboard

​

​

Perf release notes

Proof of concept of two pager

perezju@ perf release notes

​

​

​