Lines Matching full:memory
1 # Debugging memory usage on Android
18 A good place to get started investigating memory usage of a process is
20 types of memory are being used by a process.
25 Applications Memory Usage (in Kilobytes):
39 Native Heap, we can see that SystemUI's memory usage on the Java heap
42 ## Linux memory management
45 this question, we need to delve into Linux memory management a bit.
47 From the kernel's point of view, memory is split into equally sized blocks
51 (Virtual Memory Area).
53 VMAs are created when a process requests a new pool of memory pages through
61 **File-backed VMAs** are a view of a file in memory. They are obtained passing a
69 **Anonymous VMAs** are memory-only areas not backed by any file. This is the way
70 allocators request dynamic memory from the kernel. Anonymous VMAs are obtained
73 Physical memory is only allocated, in page granularity, once the application
75 touch one byte, your process' memory usage will only go up by 4KiB. You will
76 have increased your process' *virtual memory* by 32 MiB, but its resident
77 *physical memory* by 4 KiB.
79 When optimizing memory use of programs, we are interested in reducing their
80 footprint in *physical memory*. High *virtual memory* use is generally not a
84 We call the amount a process' memory that is resident in *physical memory* its
85 **RSS** (Resident Set Size). Not all resident memory is equal though.
87 From a memory-consumption viewpoint, individual pages within a VMA can have the
90 * **Resident**: the page is mapped to a physical memory page. Resident pages can
94 in case of memory pressure. This is because if they should be needed
105 which point the kernel will bring it back in main memory.
109 It is generally more important to reduce the amount of _dirty_ memory as that
110 cannot be reclaimed like _clean_ memory and, on Android, even if swapped in
111 ZRAM, will still eat part of the system memory budget.
114 *Shared* memory can be mapped into more than one process. This means VMAs in
115 different processes refer to the same physical memory. This typically happens
116 with file-backed memory of commonly used libraries (e.g., libc.so,
118 inherits dirty memory from its parent.
121 memory that is resident in multiple processes is proportionally attributed to
127 * Dynamically allocated memory, whether allocated through C's `malloc()`, C++'s
130 * If this memory is not read/written for a while, or in case of memory pressure,
132 * Anonymous memory, whether _resident_ (and hence _dirty_) or _swapped_ is
134 * File-mapped memory comes from code (java or native), libraries and resource
135 and is almost always _clean_. Clean memory also erodes the system memory
138 ## Memory over time
140 `dumpsys meminfo` is good to get a snapshot of the current memory usage, but
141 even very short memory spikes can lead to low-memory situations, which will
145 * Memory tracepoints.
150 memory information. `VmHWM` shows the maximum RSS usage the process has seen
165 ### Memory tracepoints
167 NOTE: For detailed instructions about the memory trace points see the
168 [Data sources > Memory > Counters and events](
169 /docs/data-sources/memory-counters.md) page.
171 We can use Perfetto to get information about memory management events from the
219 expand. This will show a timeline for various memory stats for camera.
221 
223 We can see that around 2/3 into the trace, the memory spiked (in the
225 how the memory usage of an application reacts to different triggers.
229 If you want to drill down into _anonymous_ memory allocated by Java code,
233 If you want to drill down into _anonymous_ memory allocated by native code,
236 up with native memory even if your app doesn't have any C/C++ code. This is
240 If you want to drill down into file-mapped memory the best option is to use
244 ## {#lmk} Low-memory kills
246 When an Android device becomes low on memory, a daemon called `lmkd` will
247 start killing processes in order to free up memory. Devices' strategies differ,
313 Applications usually get memory through `malloc` or C++'s `new` rather than
314 directly getting it from the kernel. The allocator makes sure that your memory
319 *heapprofd*. The resulting profile can be used to attribute memory usage
370 We can see that a lot of memory gets allocated in paths through
371 `ResourceManager.loadApkAssets`. To get the total memory that was allocated
378 code we can see how that memory is being used and if we actually need all of
380 into RAM rather than being able to (_cleanly_) memory-map. By not compressing
412 This will present a flamegraph of the memory attributed to the shortest path