Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(600)

Side by Side Diff: components/tracing/docs/memory_infra.md

Issue 2494063002: Move memory docs to docs/memory-infra (Closed)
Patch Set: rebase Created 4 years, 1 month ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
1 # MemoryInfra 1 This document has moved to [//docs/memory-infra/README.md](/docs/memory-infra/RE ADME.md).
2 2
3 MemoryInfra is a timeline-based profiling system integrated in chrome://tracing.
4 It aims at creating Chrome-scale memory measurement tooling so that on any
5 Chrome in the world --- desktop, mobile, Chrome OS or any other --- with the
6 click of a button you can understand where memory is being used in your system.
7
8 [TOC]
9
10 ## Getting Started
11
12 1. Get a bleeding-edge or tip-of-tree build of Chrome.
13
14 2. [Record a trace as usual][record-trace]: open [chrome://tracing][tracing]
15 on Desktop Chrome or [chrome://inspect?tracing][inspect-tracing] to trace
16 Chrome for Android.
17
18 3. Make sure to enable the **memory-infra** category on the right.
19
20 ![Tick the memory-infra checkbox when recording a trace.][memory-infra-box ]
21
22 4. For now, some subsystems only work if Chrome is started with the
23 `--no-sandbox` flag.
24 <!-- TODO(primiano) TODO(ssid): https://crbug.com/461788 -->
25
26 [record-trace]: https://sites.google.com/a/chromium.org/dev/developers/how-t os/trace-event-profiling-tool/recording-tracing-runs
27 [tracing]: chrome://tracing
28 [inspect-tracing]: chrome://inspect?tracing
29 [memory-infra-box]: https://storage.googleapis.com/chromium-docs.appspot.com/1c6 d1886584e7cc6ffed0d377f32023f8da53e02
30
31 ![Timeline View and Analysis View][tracing-views]
32
33 After recording a trace, you will see the **timeline view**. Timeline view
34 shows:
35
36 * Total resident memory grouped by process (at the top).
37 * Total resident memory grouped by subsystem (at the top).
38 * Allocated memory per subsystem for every process.
39
40 Click one of the ![M][m-blue] dots to bring up the **analysis view**. Click
41 on a cell in analysis view to reveal more information about its subsystem.
42 PartitionAlloc for instance, has more details about its partitions.
43
44 ![Component details for PartitionAlloc][partalloc-details]
45
46 The purple ![M][m-purple] dots represent heavy dumps. In these dumps, components
47 can provide more details than in the regular dumps. The full details of the
48 MemoryInfra UI are explained in its [design doc][mi-ui-doc].
49
50 [tracing-views]: https://storage.googleapis.com/chromium-docs.appspot.com/db 12015bd262385f0f8bd69133330978a99da1ca
51 [m-blue]: https://storage.googleapis.com/chromium-docs.appspot.com/b6 0f342e38ff3a3767bbe4c8640d96a2d8bc864b
52 [partalloc-details]: https://storage.googleapis.com/chromium-docs.appspot.com/02 eade61d57c83f8ef8227965513456555fc3324
53 [m-purple]: https://storage.googleapis.com/chromium-docs.appspot.com/d7 bdf4d16204c293688be2e5a0bcb2bf463dbbc3
54 [mi-ui-doc]: https://docs.google.com/document/d/1b5BSBEd1oB-3zj_CBAQWiQZ 0cmI0HmjmXG-5iNveLqw/edit
55
56 ## Columns
57
58 **Columns in blue** reflect the amount of actual physical memory used by the
59 process. This is what exerts memory pressure on the system.
60
61 * **Total Resident**: (TODO: document this).
62 * **Peak Total Resident**: (TODO: document this).
63 * **PSS**: (TODO: document this).
64 * **Private Dirty**: (TODO: document this).
65 * **Swapped**: (TODO: document this).
66
67 **Columns in black** reflect a best estimation of the the amount of physical
68 memory used by various subsystems of Chrome.
69
70 * **Blink GC**: Memory used by [Oilpan][oilpan].
71 * **CC**: Memory used by the compositor.
72 See [cc/memory][cc-memory] for the full details.
73 * **Discardable**: (TODO: document this).
74 * **Font Caches**: (TODO: document this).
75 * **GPU** and **GPU Memory Buffer**: GPU memory and RAM used for GPU purposes.
76 See [GPU Memory Tracing][gpu-memory].
77 * **LevelDB**: (TODO: document this).
78 * **Malloc**: Memory allocated by calls to `malloc`, or `new` for most
79 non-Blink objects.
80 * **PartitionAlloc**: Memory allocated via [PartitionAlloc][partalloc].
81 Blink objects that are not managed by Oilpan are allocated with
82 PartitionAlloc.
83 * **Skia**: (TODO: document this).
84 * **SQLite**: (TODO: document this).
85 * **V8**: (TODO: document this).
86 * **Web Cache**: (TODO: document this).
87
88 The **tracing column in gray** reports memory that is used to collect all of the
89 above information. This memory would not be used if tracing were not enabled,
90 and it is discounted from malloc and the blue columns.
91
92 <!-- TODO(primiano): Improve this. https://crbug.com/??? -->
93
94 [oilpan]: /third_party/WebKit/Source/platform/heap/BlinkGCDesign.md
95 [cc-memory]: /cc/memory.md
96 [gpu-memory]: memory_infra_gpu.md
97 [partalloc]: /third_party/WebKit/Source/wtf/allocator/PartitionAlloc.md
98
99 ## Related Pages
100
101 * [Adding MemoryInfra Tracing to a Component](adding_memory_infra_tracing.md)
102 * [GPU Memory Tracing](memory_infra_gpu.md)
103 * [Heap Profiler Internals](heap_profiler_internals.md)
104 * [Heap Profiling with MemoryInfra](heap_profiler.md)
105 * [Startup Tracing with MemoryInfra](memory_infra_startup_tracing.md)
106
107 ## Rationale
108
109 Another memory profiler? What is wrong with tool X?
110 Most of the existing tools:
111
112 * Are hard to get working with Chrome. (Massive symbols, require OS-specific
113 tricks.)
114 * Lack Chrome-related context.
115 * Don't deal with multi-process scenarios.
116
117 MemoryInfra leverages the existing tracing infrastructure in Chrome and provides
118 contextual data:
119
120 * **It speaks Chrome slang.**
121 The Chromium codebase is instrumented. Its memory subsystems (allocators,
122 caches, etc.) uniformly report their stats into the trace in a way that can
123 be understood by Chrome developers. No more
124 `__gnu_cxx::new_allocator< std::_Rb_tree_node< std::pair< std::string const, base::Value*>>> ::allocate`.
125 * **Timeline data that can be correlated with other events.**
126 Did memory suddenly increase during a specific Blink / V8 / HTML parsing
127 event? Which subsystem increased? Did memory not go down as expected after
128 closing a tab? Which other threads were active during a bloat?
129 * **Works out of the box on desktop and mobile.**
130 No recompilations with unmaintained `GYP_DEFINES`, no time-consuming
131 symbolizations stages. All the logic is already into Chrome, ready to dump at
132 any time.
133 * **The same technology is used for telemetry and the ChromePerf dashboard.**
134 See [the slides][chromeperf-slides] and take a look at
135 [some ChromePerf dashboards][chromeperf] and
136 [telemetry documentation][telemetry].
137
138 [chromeperf-slides]: https://docs.google.com/presentation/d/1OyxyT1sfg50lA36A7ib Z7-bBRXI1kVlvCW0W9qAmM_0/present?slide=id.gde150139b_0_137
139 [chromeperf]: https://chromeperf.appspot.com/report?sid=3b54e60c995165657 4e19252fadeca846813afe04453c98a49136af4c8820b8d
140 [telemetry]: https://catapult.gsrc.io/telemetry
141
142 ## Development
143
144 MemoryInfra is based on a simple and extensible architecture. See
145 [the slides][dp-slides] on how to get your subsystem reported in MemoryInfra,
146 or take a look at one of the existing examples such as
147 [malloc_dump_provider.cc][malloc-dp]. The crbug label is
148 [Hotlist-MemoryInfra][hotlist]. Don't hesitate to contact
149 [tracing@chromium.org][mailtracing] for questions and support.
150
151 [dp-slides]: https://docs.google.com/presentation/d/1GI3HY3Mm5-Mvp6eZyVB0JiaJ- u3L1MMJeKHJg4lxjEI/present?slide=id.g995514d5c_1_45
152 [malloc-dp]: https://chromium.googlesource.com/chromium/src.git/+/master/base/ trace_event/malloc_dump_provider.cc
153 [hotlist]: https://code.google.com/p/chromium/issues/list?q=label:Hotlist-Me moryInfra
154 [mailtracing]: mailto:tracing@chromium.org
155
156 ## Design documents
157
158 Architectural:
159
160 <iframe width="100%" height="300px" src="https://docs.google.com/a/google.com/em beddedfolderview?id=0B3KuDeqD-lVJfmp0cW1VcE5XVWNxZndxelV5T19kT2NFSndYZlNFbkFpc3p Sa2VDN0hlMm8">
161 </iframe>
162
163 Chrome-side design docs:
164
165 <iframe width="100%" height="300px" src="https://docs.google.com/a/google.com/em beddedfolderview?id=0B3KuDeqD-lVJfndSa2dleUQtMnZDeWpPZk1JV0QtbVM5STkwWms4YThzQ0p GTmU1QU9kNVk">
166 </iframe>
167
168 Catapult-side design docs:
169
170 <iframe width="100%" height="300px" src="https://docs.google.com/a/google.com/em beddedfolderview?id=0B3KuDeqD-lVJfm10bXd5YmRNWUpKOElOWS0xdU1tMmV1S3F4aHo0ZDJLTmt GRy1qVnQtVWM">
171 </iframe>
OLDNEW
« no previous file with comments | « components/tracing/docs/heap_profiler_internals.md ('k') | components/tracing/docs/memory_infra_gpu.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698