olka@chromium.org fhernqvist@google.com tguilbert@chromium.org webrtc-audio-uma@google.com xhwang@chromium.org media-dev-uma@chromium.org xhwang@chromium.org media-dev-uma@chromium.org ckitagawa@chromium.org fredmello@chromium.org jam@chromium.org joenotcharles@google.com chrome-memory@google.com One metric is emitted on every process start, recording whether the in-process heap profiler is enabled in {Process} for this Chrome session. joenotcharles@google.com chrome-memory@google.com The number of samples in a heap snapshot taken in {Process}. Emitted once per snapshot when the in-process heap profiler is enabled. joenotcharles@google.com chrome-memory@google.com The ratio of the actual sampling interval in use to the requested sampling interval, as a percentage. 100% means the actual interval matches the requested interval. Values less than 100% mean the actual interval is smaller (sampling is more frequent). Values greater than 100% mean the actual interval is larger (sampling is less frequent). Emitted once per snapshot in {Process}. joenotcharles@google.com etienneb@chromium.org chrome-memory@google.com The total amount of memory in a heap snapshot taken in {Process}. This is an estimate of total memory allocations in the code being sampled. Because it is collected through random sampling it is only statistically accurate when aggregated over many reports. Emitted once per snapshot when the in-process heap profiler is enabled. lizeb@chromium.org chrome-memory@google.com How many memory mappings are present in the process, at the time of recording. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms, only on Linux-based systems. erikchen@chromium.org justincohen@chromium.org chrome-analysis-team@google.com This metric is only recorded on iOS. This measures the sum of PrivateMemoryFootprint and SharedMemoryFootprint, which is possible because Chromium on iOS is single-process. Note that this does not include memory consumed by WebKit-launched processes, such as the WebContent and Network processes. Emitted when closing a log in order to upload it. This happens shortly after startup and again at regular intervals (usually 5 minutes, regardless of the type of network connection). Not emitted in logs that are closed when Chrome loses focus or closes. Yet, it is emitted on logs that are constructed from data persisted from a previous session, i.e., persisted from an unclean shutdown. Many changes in memory usage on iOS come from changes to WebKit, rather than changes within Chromium code. To assess whether a change in this metric is caused by a WebKit change, split by OS version. WebKit changes always come with an OS version change. As with other memory metrics, memory use tends to increase over time. Restarts due to OS or Chrome updates tend to make this metric drop. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. justincohen@chromium.org bling-fundamentals@google.com This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but only recorded when UIApplication.sharedApplication.applicationState is UIApplicationStateActive. justincohen@chromium.org bling-fundamentals@google.com This metric is only recorded on iOS when UIApplication.sharedApplication.applicationState is UIApplicationStateActive. True if the sum of PrivateMemoryFootprint and SharedMemoryFootprint is greater than 200MB. According to Apple, apps on iPhone 6 and older devices get terminated by the OS if memory usage crosses 200MB watermark, so it's important to keep the memory usage under 200MB. "true" value may not show up on iPhone 6 and older devices if iOS is strict about the advertised watermark. justincohen@chromium.org bling-fundamentals@google.com This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but only recorded when UIApplication.sharedApplication.applicationState is UIApplicationStateBackground. According to Apple, apps get terminated by the OS if memory usage in background crosses 50MB watermark, so it's important to keep the memory usage under 50MB. The timing of this metric will line up so that it rarely occurs when the app is in the background. With a small data set, the metrics might be biased in ways that we can't think of right now. justincohen@chromium.org bling-fundamentals@google.com This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but only recorded when UIApplication.sharedApplication.applicationState is UIApplicationStateInactive. The timing of this metric will line up so that it rarely occurs when the app is inactive. With a small data set, the metrics might be biased in ways that we can't think of right now. justincohen@chromium.org rkgibson@google.com Investigation into crbug.com/1102494 shows that OverscrollActionsController is allocating thousands of objects in it's -initWithScrollView:. This is likely because thousands of OverscrollActionsControllers are being initialized. The theory is that there are users that have many many tabs, causing many OverscrollActionsControllers to be allocated. This histogram tests that theory by logging how many open tabs there are. This is recorded every time histograms are uploaded. justincohen@chromium.org bling-fundamentals@google.com This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but recorded right after the app transitions into background. According to Apple, apps get terminated by the OS if memory usage in background crosses 50MiB watermark so it's important to keep the memory usage under 50MiB. justincohen@chromium.org bling-fundamentals@google.com This metric is only recorded on iOS. Same as Memory.Browser.MemoryFootprint but recorded during startup after the deferred initialization blocks queue becomes empty. colibie@google.com src/android_webview/OWNERS WARNING: Android WebView Only at the moment. The total active memory (bytes currently occupied by live objects) managed by PartitionAlloc-as-Malloc in the browser process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android (WebView). erikchen@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of the browser process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. erikchen@chromium.org ssid@chromium.org An amount of private memory of the browser process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. fdoray@chromium.org The size of the resident memory in the browser process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. colibie@google.com src/android_webview/OWNERS Recorded only for Android WebView. The peak size of the resident memory in the browser process (also known as RSS High Water Mark). Recorded at Poisson sampled time intervals with a mean of 5 minutes. erikchen@chromium.org A rough estimate of the shared memory footprint of the browser process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note #1: Incorrect metrics were reported for M140; there was no actual regression. Details can be found at crbug.com/450560777 and crrev.com/c/7041925. aattar@google.com catan-team@chromium.org Reported for Windows only. This represents the amount of virtual memory currently available for the system to commit, measured in megabytes. This value is obtained directly from the ullAvailPageFile field of the MEMORYSTATUSEX struct returned by the GlobalMemoryStatusEx API. It indicates the remaining capacity for applications to commit memory before reaching the system's commit limit. This value is recorded at the same time as the current memory pressure signal. aattar@google.com catan-team@chromium.org Reported for Windows only. This represents the total amount of virtual memory that can be committed on the system. Virtual memory includes both physical RAM and the page file on disk. This metric essentially shows the upper limit of memory the system can utilize. This value is recorded at the same time as the current memory pressure signal. This value is recorded at the same time as the current memory pressure signal. aattar@google.com catan-team@chromium.org Reported for Windows only. This metric provides a clear picture of memory utilization by expressing the currently committed memory as a percentage of the CommitLimit. It helps assess how heavily the system is relying on its virtual memory resources. This value is recorded at the same time as the current memory pressure signal. kmg@google.com catan-team@chromium.org The number of child-process memory consumer registrations coalesced into a single batched RegisterMany() IPC to the browser's memory coordinator. Recorded once each time a child process flushes its pending registrations. A value of 1 means no coalescing happened for that flush; larger values quantify how effectively the per-consumer registration IPCs are batched. thiabaud@google.com lizeb@chromium.org Freelist size used by ClientDiscardableMemoryManager in the foreground only. Recorded during |OnMemoryDump|. thiabaud@google.com lizeb@chromium.org Boolean metric which tracks whether or not large chunks of discardable memory are allocated from the freelist or via IPC. thiabaud@google.com lizeb@chromium.org Boolean metric which tracks whether or not discardable memory had already been discarded when an attempt is made to lock it. thiabaud@google.com lizeb@chromium.org Effective memory used by ClientDiscardableMemoryManager in the foreground only. Recorded during |OnMemoryDump|. thiabaud@google.com lizeb@chromium.org Virtual memory used by ClientDiscardableMemoryManager in the foreground only. Recorded during |OnMemoryDump|. reveman@chromium.org thiabaud@google.com The discardable memory allocation size in KB. Recorded each time a new discardable memory instance is created. joenotcharles@google.com chrome-catan@google.com Logged whenever a memory dump starts for {DetailLevel}, with the reason the dump is being requested. joenotcharles@google.com chrome-catan@google.com The number of instances of MemoryDumpProvider {Name} that are queued during a memory dump. Logged whenever a memory dump starts for {DetailLevel}. joenotcharles@google.com chrome-catan@google.com The status of an instance of MemoryDumpProvider {Name} when it finishes running or is skipped. During a memory dump, a list of MemoryDumpProvider objects is queued to run in sequence. This metric is logged for each object in a dump of {DetailLevel} when it's destroyed, with the reason it was destroyed. Usually this is when it's removed from the queue to run it, or to explicitly skip it. Objects can also be destroyed if they're still in the queue when the queue is destroyed. joenotcharles@google.com chrome-catan@google.com The number of MemoryDumpProviders remaining in the queue for a dump of {DetailLevel} after an instance of MemoryDumpProvider {Name} is destroyed. Logged at the same time as Memory.DumpProvider.FinalStatus. joenotcharles@google.com chrome-catan@google.com The length of time an instance of MemoryDumpProvider {Name} spent executing for {DetailLevel}, not including time the system was suspended. Memory.DumpProvider.TotalTime, which includes the time it spent queued, will also be logged when this is logged. Note: this metric is only recorded on clients with a high-resolution clock. joenotcharles@google.com chrome-catan@google.com The length of time between an instance of MemoryDumpProvider {Name} being posted to take a memory dump for {DetailLevel} on another thread, and Memory.DumpProvider.FinalStatus being recorded for that instance, not including time the system was suspended. If FinalStatus was recorded because the instance finished running, Memory.DumpProvider.MemoryDumpTime will also be recorded with the time that it took to run. Note: this metric is only recorded on clients with a high-resolution clock. joenotcharles@google.com chrome-catan@google.com The length of time between an instance of MemoryDumpProvider {Name} being queued for a memory dump of {DetailLevel}, and Memory.DumpProvider.FinalStatus being recorded for that instance, not including time the system was suspended. If FinalStatus was recorded because the instance finished running, Memory.DumpProvider.MemoryDumpTime will also be recorded with the time that it took to run. Note: this metric is only recorded on clients with a high-resolution clock. anthonyvd@chromium.org catan-team@chromium.org The amount of available physical memory on the system as reported by base::SysInfo::AmountOfAvailablePhysicalMemory(). Recorded every 2 minutes. anthonyvd@chromium.org catan-team@chromium.org The percentage of physical memory on the system considered "available" by base::SysInfo::AmountOfAvailablePhysicalMemory() and base::SysInfo::AmountOfTotalPhysicalMemory(). Recorded every 2 minutes. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorCustom2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorSmall2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorTiny2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The browser process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocator2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorCustom2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorSmall2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorTiny2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The extension process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocator2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorCustom2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorSmall2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorTiny2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The gpu process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocator2} anthonyvd@chromium.org catan-team@chromium.org The amount of memory reported as "file-backed" or associated to "external_pages" by vm_stat. Recorded every 2 minutes on MacOS. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorCustom2} Warning: this histogram was expired from 2026-01-10 to 2026-03-10; data may be missing. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in KiB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorSmall2} Warning: this histogram was expired from 2026-01-10 to 2026-03-10; data may be missing. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorTiny2} Warning: this histogram was expired from 2025-05-25 to 2026-03-10; data may be missing. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The network service process's memory usage reported by the memory instrumentation service in MiB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocator2} etiennep@chromium.org fdoray@chromium.org The amount of available memory on the system as reported by MemAvailable from /proc/meminfo when a foreground renderer OOM occurs. This is recorded during OOM handling, it is not guaranteed that the value reflects the state at the time of the OOM. Recorded on Android. etiennep@chromium.org fdoray@chromium.org The amount of available memory on the system as reported by MemAvailable from /proc/meminfo when a foreground renderer OOM occurs. This is the last recorded metric by renderer a few seconds before getting killed. Recorded on Android. tasak@google.com mikt@chromium.org The highest private memory footprint of a renderer process in (X mins after the first page navigation, Y mins after the first page navigation]. (X, Y] is (0, 2], (2, 4], (4, 8], and (8, 16]. The metric is recorded at the Y's timing. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. etiennep@chromium.org fdoray@chromium.org Amount of swap space as reported by SwapFree from /proc/meminfo when a foreground renderer OOM occurs. This is recorded during OOM handling, it is not guaranteed that the value reflects the state at the time of the OOM. Recorded on Android. etiennep@chromium.org fdoray@chromium.org Amount of swap space as reported by SwapFree from /proc/meminfo when a foreground renderer OOM occurs. This is the last recorded metric by renderer a few seconds before getting killed. Recorded on Android. etiennep@chromium.org fdoray@chromium.org The total amount of memory on the system as reported by MemTotal from /proc/meminfo when a foreground renderer OOM occurs. This is recorded during OOM handling, it is not guaranteed that the value reflects the state at the time of the OOM. Recorded on Android. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorCustom2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorSmall2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorTiny2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The renderer process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocator2} keishi@chromium.org tasak@chromium.org The renderer process' private memory footprint right before a memory pressure signal is generated. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. tasak@google.com chrome-memory-tok@google.com The total private memory footprint excluding lower priority renderers' 10 seconds after a user-level memory pressure signal is generated. Recorded on Android. tasak@google.com chrome-memory-tok@google.com The total private memory footprint excluding lower priority renderers' right before a user-level memory pressure signal is generated. Recorded on Android. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorCustom2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in KB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorSmall2} sashamcintosh@chromium.org chromeos-gfx@chromium.org erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in bytes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocatorTiny2} erikchen@chromium.org ssid@chromium.org lizeb@chromium.org The utility process's memory usage reported by the memory instrumentation service in MB. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. {ProcessMemoryAllocator2} erikchen@chromium.org ssid@chromium.org A rough estimate of the private memory footprint of the extension process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. fdoray@chromium.org The size of the resident memory in an extension process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. lizeb@chromium.org chrome-memory@google.com How many memory mappings are present in the process, at the time of recording. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms, only on Linux-based systems. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org The maximum amount of memory of the GPU process allocated by {Source} during the following user interaction: {Usage}. See Memory.GPU.PeakMemoryUsage2. jonross@chromium.org chrome-gpu-metric-alerts@chromium.org The maximum amount of memory of the GPU process during the following user interaction: {Usage}. erikchen@chromium.org ssid@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of the gpu process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. WARNING: This metric does not include the footprint of the graphics buffers on all platforms. Concretely, this means that on these platforms, this metric will drastically underestimate the true cost of rendering. On devices with unified memory (most Android, laptop and desktop clients with integrated graphics, and all ARM64 mac clients), graphics buffers come from the same memory pool as system RAM. For more details, alternative metrics to monitor, and the state of various platforms, see docs/memory/graphics_metrics.md. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. fdoray@chromium.org The size of the resident memory in the GPU process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the gpu process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note #1: Incorrect metrics were reported for M140; there was no actual regression. Details can be found at crbug.com/450560777 and crrev.com/c/7041925. hajimehoshi@chromium.org erikchen@chromium.org kenjibaheux@google.com kouhei@chromium.org bgeffon@chromium.org System-wide graphics driver memory consumption. Recorded on Chrome OS for platforms where it is exposed by the kernel (for example, Intel i915 and Exynos Mali). Recorded once per UMA ping. khmel@google.com vovoy@google.com Cumulative count of low memory kills in one user session. This is recorded by MemoryKillsMonitor every time a low memory kill occurs. khmel@google.com vovoy@google.com When Chrome OS is in low memory state, TabManager kills some victims to free memory. This value is the elapsed time between TabManager receiving the low memory notification and the first kill. Warning: this histogram was expired from 2024-12-08 to 2026-08-17; data may be missing. khmel@google.com vovoy@google.com The memory size freed by each low memory kill event. Warning: this histogram was expired from 2024-07-21 to 2026-08-17; data may be missing. fdoray@chromium.org catan-team@chromium.org The outcome of memory dump request made to emit memory metrics. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Many other memory metrics, including Memory.*.PrivateMemoryFootprint, will not be recorded when this does not indicate a success. This can be used as a diagnosis metric when the count of other memory metrics drops. lizeb@chromium.org pasko@chromium.org The size of the resident memory for the native library code across all processes. This metric is computed by parsing proc/self/pagemap and counting native library pages that are mapped and present in RAM for at least one Chrome process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org pasko@chromium.org Result of an attempt to read /proc/self/pagemap when determining the amount of resident memory mapped by the current process. Reading the file is performed as part of computing the Memory.NativeLibrary.MappedAndResidentMemoryFootprint2 histogram. Available only on Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org pasko@chromium.org The size of the native library code which was ordered, yet is not resident in memory, across all processes. This metric is computed by parsing proc/self/pagemap and counting native library pages that are mapped and present in RAM for at least one Chrome process. Available only on Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org pasko@chromium.org The size of the native library code which is outside the ordered section, yet is resident in memory, across all processes. This metric is computed by parsing proc/self/pagemap and counting native library pages that are mapped and present in RAM for at least one Chrome process. Available only on Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org A rough estimate of the private memory footprint of the network service process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org An amount of private memory of the network service process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: Histogram data may be missing for mid-2020 due to expiry. mmenke@chromium.org morlovich@chromium.org erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the network service process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note #1: Histogram data may be missing for mid-2020 due to expiry. Note #2: Incorrect metrics were reported for M140; there was no actual regression. Details can be found at crbug.com/450560777 and crrev.com/c/7041925. vovoy@google.com wvk@google.com Cumulative count of OOM kills in one user session. vovoy@google.com src/chromeos/ash/components/memory/OWNERS The number of OOM kills since last emit. The emit interval is at least 24 hours, see metrics::DailyEvent for more details. thiabaud@google.com lizeb@chromium.org Size of encoded image data of ParkableImages that are on disk. Collected once, 5 minutes after the first ParkableImage is created. This histogram was expired before 2024-03-19, be careful of missing data. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is read from disk. Records the time taken to read a ParkableImage from disk. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. This histogram was expired before 2024-03-19, be careful of missing data. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is read from disk. Records the throughput of reading the ParkableImage from disk, in MiB/s. thiabaud@google.com lizeb@chromium.org Total time spent reading images from disk. Collected once, 5 minutes after the first ParkableImage is created. This histogram was expired before 2024-03-19, be careful of missing data. thiabaud@google.com lizeb@chromium.org Total size of encoded image data of ParkableImages. Collected once, 5 minutes after the first ParkableImage is created. This histogram was expired before 2024-03-19, be careful of missing data. thiabaud@google.com lizeb@chromium.org Total time spent writing images to disk. Collected once, 5 minutes after the first ParkableImage is created. thiabaud@google.com lizeb@chromium.org Size of encoded image data of ParkableImages that are not written to disk. Collected once, 5 minutes after the first ParkableImage is created. This histogram was expired before 2024-03-19, be careful of missing data. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is written to disk. Records the time taken to write the ParkableImage to disk. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. This histogram was expired before 2024-03-19, be careful of missing data. thiabaud@google.com lizeb@chromium.org Recorded each time a ParkableImage is written to disk. Records the size of the write, in KiB. This histogram was expired before 2024-03-19, be careful of missing data. lizeb@chromium.org thiabaud@google.com Time to compress a ParkableString, in us. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. lizeb@chromium.org thiabaud@google.com Size of a compressed ParkableString, recorded at compression time. lizeb@chromium.org thiabaud@google.com Time to decompress a ParkableString, in us. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. This histogram was expired before 2024-03-19, be careful of missing data. lizeb@chromium.org thiabaud@google.com Original size of a compressed ParkableString, recorded at decompression time. This histogram was expired before 2024-03-19, be careful of missing data. lizeb@chromium.org pasko@chromium.org Total main thread time used by ParkableStrings for reading over the first 5 minutes of a renderer lifetime. Starting time is from the first ParkableString being added. lizeb@chromium.org pasko@chromium.org Total time used by ParkableStrings for writing to disk over the first 5 minutes of a renderer lifetime. Starting time is from the first ParkableString being added. This histogram was expired before 2024-03-19, be careful of missing data. lizeb@chromium.org pasko@chromium.org Total size of ParkableStrings discarded to disk, excluding allocator waste, in KB. Recorded once, 5 minutes after the first ParkableString is added to a renderer, at the same time as "Memory.ParkableString.MemorySavings.5min". This histogram was expired before 2024-03-19, be careful of missing data. lizeb@chromium.org pasko@chromium.org Time to read a ParkableString from disk, in us. Note: This metric drops reports on clients with low-resolution clocks, which means these reports will be biased against a portion of the population on Windows. See Windows.HasHighResolutionTimeTicks for the affected sample. This histogram was expired before 2024-03-19, be careful of missing data. lizeb@chromium.org pasko@chromium.org Total thread time (on background threads) used by ParkableStrings for compression over the first 5 minutes of a renderer lifetime. Starting time is from the first ParkableString being added. This always happens on background thread, so the reported value is thread time, not wall clock. lizeb@chromium.org pasko@chromium.org Total time used by ParkableStrings for unparking over the first 5 minutes of a renderer lifetime. Starting time is from the first ParkableString being added. Note that unparking can happen on the main thread or on a background one, so this is not the sum of main thread time. nuskos@chromium.org chrome-cpp-runtime-safety@google.com Whether PartitionAlloc's core pool size was reduced on iOS due to initial allocation failure. This can happen on devices or in processes that lack the extended virtual address space entitlement. Recorded once during allocator shim configuration. keishi@chromium.org kdlee@chromium.org Size of the extras configured for PartitionAlloc's `PartitionRoot` struct. This is specific to the main partition, which powers the bulk of PartitionAlloc-Everywhere. Recorded once for each process during allocator shim configuration. Extras are optional. Extras can include the PartitionAlloc cookie (16B) and the MiraclePtr ref-count (up to 16B). yukishiino@chromium.org lizeb@chromium.org Time it takes for PartitionAlloc's periodic purge to run once. Collected at each purge, for all process types. Note that clients without high-resolution clocks will report 0 for very short times. Subsampled to 1/100. thiabaud@google.com lizeb@google.com Recorded when a pre-freeze notification arrives or when we try to record metrics (after pre-freeze trimming should have finished) and fail. thiabaud@google.com lizeb@google.com The private memory footprint of {Process}, recorded when we get a notification that the application is about to be frozen. {Timing} Recorded only on Android 14+, and only recorded if at least one task has been registered with PreFreeze. thiabaud@google.com lizeb@google.com The Vulkan memory usage of {Process}, recorded when we get a notification that the application is about to be frozen. {Timing} Recorded only on Android 14+, and only recorded if at least one task has been registered with PreFreeze, and only if Vulkan is being used. fdoray@chromium.org catan-team@chromium.org The time spent in each memory pressure state, in seconds. Recorded when the memory pressure state changes, at shutdown, or when it hasn't been recorded in the last 5 minutes. The values from this histogram shouldn't be used directly, users of this metric should look at the percentage of samples in each bucket to understand the average time that Chrome spend in each pressure state. fdoray@chromium.org catan-team@chromium.org The time spent in each of the memory pressure state. Recorded when transitioning from a memory pressure state to the other and when exiting memory pressure. creis@chromium.org nasko@chromium.org The count of all active processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. jonross@chromium.org chrome-gpu-memory@google.com The estimated memory size of viz::TransferableResources that are locked against deletion. This is reported by a ClientResourceProvider once it has been evicted by the Viz Host, and whose cc::LayerTreeHostImpl has been hidden. This counts the {Source} that are locked. These will not be freed when Viz instructs us to ReclaimResources. lizeb@chromium.org chrome-memory@google.com How many memory mappings are present in the process, at the time of recording. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms, only on Linux-based systems. erikchen@chromium.org ssid@chromium.org speed-metrics-dev@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of the renderer process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. Do not modify this metric in any way without contacting speed-metrics-dev@chromium.org AND chrome-analysis-team@google.com. erikchen@chromium.org ssid@chromium.org An amount of private memory of the renderer process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. fdoray@chromium.org The size of the resident memory in a renderer process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. colibie@google.com src/android_webview/OWNERS Recorded only for Android WebView. The peak size of the resident memory in a renderer process (also known as RSS High Water Mark). Recorded at Poisson sampled time intervals with a mean of 5 minutes. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the renderer process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note #1: Incorrect metrics were reported for M140; there was no actual regression. Details can be found at crbug.com/450560777 and crrev.com/c/7041925. creis@chromium.org nasko@chromium.org The count of active renderer processes. Excludes renderers hosting chrome-extension:// and/or chrome:// URLs. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Computed based on OS data. WARNINGS: Not reliable on Android, see https://crbug.com/875400. Ignores processes that do not host a widget, see https://crbug.com/949977#c36. Consider using Memory.RenderProcessHost.Count2.* instead. alexmos@chromium.org creis@chromium.org lukasza@chromium.org nasko@chromium.org The count of all renderer processes. Covers all renderer processes, including ones hosting web content (i.e. http(s):// and/or file://), extensions (i.e. chrome-extension://) and WebUI (i.e. chrome://). Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Computed based on count of RenderProcessHost objects, even if 1) they have not been launched yet (e.g. during session restore) or 2) they are dead (e.g. killed by the browser process or the OS). alexmos@chromium.org creis@chromium.org lukasza@chromium.org nasko@chromium.org The count of active renderer processes. Recorded once per UMA ping. Covers all renderer processes, including ones hosting web content (i.e. http(s):// and/or file://), extensions (i.e. chrome-extension://) and WebUI (i.e. chrome://). Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Computed based on count of RenderProcessHost objects that are IsInitializedAndNotDead (i.e. have been launched and not terminated yet). wjmaclean@chromium.org alexmos@chromium.org creis@chromium.org An estimate of additional processes created due to origin-keyed processes, including OriginAgentCluster (OAC) headers and OriginKeyedProcessesByDefault mode. Computed assuming no coalescing of multiple BrowsingInstances into a single RenderProcess (including no subframe process reuse), and only when cross-process origin isolation occurs due to the OAC header or OriginKeyedProcessesByDefault. Given this, the count of additional SiteInstances corresponds exactly to the additional number of RenderProcesses that that are due to origin-keying, and therefore gives a sense of how much process count overhead it creates. Recorded once per UMA ping. Note: when the feature OriginKeyedProcessesByDefault is enabled, all navigations are treated as if the OAC opt-in header is present, unless the OAC opt-out header is present. As a result, any analyses of this metric should separate users with and without OriginKeyedProcessesByDefault, to distinguish actual header adoption. wjmaclean@chromium.org alexmos@chromium.org creis@chromium.org The number of renderer processes that represent sandboxed iframes, computed by counting the number of RenderProcessHosts allocated to them. This will be zero when SiteIsolationPolicy::AreIsolatedSandboxedIframesEnabled() is false. Recorded once per UMA ping. wjmaclean@chromium.org alexmos@chromium.org creis@chromium.org The percentage of the total renderer process count that is due to origin-keyed processes, based on the overhead estimate from Memory.RenderProcessHost.Count2.OriginAgentClusterProcesses. That value is computed assuming no coalescing of multiple BrowsingInstances into a single RenderProcess (including no subframe process reuse), and only when cross-process origin isolation occurs due to origin-keying. Given this, the percentage of total SiteInstances due to origin-keying corresponds exactly to the percentage of RenderProcesses that origin-keying gives rise to. Recorded once per UMA ping. Note: when the feature OriginKeyedProcessesByDefault is enabled, all navigations are treated as if the OAC opt-in header is present, unless the OAC opt-out header is present. As a result, any analyses of this metric should separate users with and without OriginKeyedProcessesByDefault, to distinguish actual header adoption. thiabaud@google.com lizeb@google.com The reason that self-compaction or running-compaction was cancelled. Recorded once each time compaction is cancelled while running. This metric is used for both self-compaction and running-compaction. iby@chromium.org chromeos-data-eng@google.com The size of the stack copied during a stack profiler capture. One sample per 199 stack captures. Only recorded by clients in the stack-sampled metrics experiment or recording a Chrometto trace. ChromeOS only. hidehiko@chromium.org System-wide estimate of memory available in ChromeOS, without swapping. Calculated from MemFree, SReclaimable, the size of the file LRU lists, and the low watermarks in each zone. The estimate takes into account that the system needs some page cache to function well, and that not all reclaimable slab will be reclaimable, due to items being in use. hidehiko@chromium.org System-wide estimate of memory used in ChromeOS, calculated as the difference between the amount of total and available memory. spvm@google.com etienneb@google.com Recorded on Windows only. The status if unsuccessful of querying for the size of system memory lists. If Recorded at-most once per startup 100ms after browser message loop starts, and only if we never record Memory.SystemMemoryLists.ExhaustedIntervalsPerThirtySeconds because of the failed query. spvm@google.com etienneb@google.com The size of the system memory list of the standby list at priority {Priority}. Recorded on Windows only. Recorded every 30s, after browser main message loop start. spvm@google.com etienneb@google.com Recorded on Windows only. The SystemMemoryPressureEvaluator attempts to query the size of the system memory lists 300 times per 30 seconds. This metric records the actual number of times the lists were queried per thirty seconds, in the case that due to contention, the evaluator is unable to run. Recorded every 30s after browser main message loop start. spvm@google.com etienneb@google.com Recorded on Windows only. Every 100ms, the size of the system memory lists are queried (and if this query fails, the entire process is cancelled and Memory.SystemMemoryLists.QueryFailureStatus is recorded instead). This metric is the total number of consecutive queries over the course of 30s (at least two in a row to qualify, but several runs can occur disjointedly) that returned that {PageList} had {Level} pages. Emitted every 30s in the browser process after main message loop start. spvm@google.com etienneb@google.com The size of the system memory list of {PageCount}. Recorded on Windows only. Recorded every 30s, after browser main message loop start. lizeb@chromium.org chrome-memory@chromium.org Total size of all mapped memory buffers for GPU to/from client transfers. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. lizeb@chromium.org chrome-memory@chromium.org Total size of all hibernated canvases across all renderers, prior to compression. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. lizeb@chromium.org chrome-memory@chromium.org Total size of all hibernated canvases across all renderers. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. erikchen@chromium.org ssid@chromium.org chrome-analysis-team@google.com A rough estimate of the private memory footprint of all processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. This histogram is of special interest to the chrome-analysis-team@. Do not change its semantics or retire it without talking to them first. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all processes on Android ignoring Renderers with only Waived process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all visible or higher importance processes on Android. This ignores Renderers with Waived or Not Perceptible effective process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. thiabaud@google.com lizeb@chromium.org An amount of private memory of all processes placed in swap (VmSwap). Available on Android only. Recorded at Poisson sampled time intervals with a mean of 5 minutes. fdoray@chromium.org lizeb@chromium.org Memory from the Blink heap in all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. fdoray@chromium.org lizeb@chromium.org Memory from the Blink heap which is not used by allocated objects in all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. keishi@chromium.org kdlee@chromium.org A rough estimate of memory allocated by malloc in all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. tommckee@chromium.org A rough estimate of the private memory footprint of all renderer processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all renderer processes on Android ignoring Renderers with only Waived process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. ckitagawa@chromium.org yfriedman@chromium.org A rough estimate of the private memory footprint of all renderer processes with visible or higher importance on Android. This ignores Renderers with Waived or Not Perceptible effective process bindings. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android. thiabaud@google.com lizeb@chromium.org An amount of private memory of all renderer processes placed in swap (VmSwap). Available on Android only. Recorded at Poisson sampled time intervals with a mean of 5 minutes. fdoray@chromium.org The size of the resident memory in all processes. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: This metric is a simple sum of the resident set of all processes and this cause some double accounting for the shared portion of the working set. As a result this metric doesn't give an exact representation of how much physical memory is used by Chrome. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of all processes. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note #1: Incorrect metrics were reported for M140; there was no actual regression. Details can be found at crbug.com/450560777 and crrev.com/c/7041925. zmo@chromium.org chrome-gpu-metric-alerts@chromium.org Records the system commit limit (number of total pages) x page size, collected in the info collection GPU process, once per UMA ping. This is Windows platform only. lizeb@chromium.org chrome-gpu-memory@google.com Total (GPU) memory used for tiles, across all consumers. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. lizeb@chromium.org chrome-memory@google.com How many memory mappings are present in the process, at the time of recording. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms, only on Linux-based systems. kalutes@google.com cwd@google.com cros-vm-technology@google.com The time the Virtual Machine Memory Management Service added to a kill decision from a client. Logged after a client asks the VMMMS to change a balloon size to avoid killing an app or discarding a tab. kalutes@google.com cwd@google.com cros-vm-technology@google.com The priority of each kill decision request that timed out. Logged after a client asks the VMMMS to change a balloon size to avoid killing an app or discarding a tab. kalutes@google.com cwd@google.com cros-vm-technology@google.com The priority of each kill decision request that timed out leading to an unnecessary app kill or tab discard. Logged after a client asks the VMMMS to change a balloon size to avoid killing an app or discarding a tab. kalutes@google.com cwd@google.com cros-vm-technology@google.com When the balloon for a given VM is deflated, the size of the deflation. kalutes@google.com cwd@google.com cros-vm-technology@google.com When the balloon for a given VM is inflated, the size of the inlfation. kalutes@google.com cwd@google.com cros-vm-technology@google.com When the balloon for a given VM resizes, the time since the previous resize. kalutes@google.com cwd@google.com cros-vm-technology@google.com The size of the balloon for a given VM. Logged every 10 minutes. kalutes@google.com cwd@google.com cros-vm-technology@google.com The inflation rate of a balloon when a stall is detected. kawasin@google.com sstan@google.com The total bytes written by vmm-swap feature for a week. This is sent weekly once any disk writes for vmm-swap has done. Once reporting has started it reports weekly even if the total bytes written is zero. kawasin@google.com sstan@google.com The duration how long it was spent with vmm-swap enabled. This is sent with ".InactiveBeforeEnableDuration" metrics when vmm-swap is disabled. Shorter ".InactiveBeforeEnableDuration" and longer ".ActiveAfterEnableDuration" indicates the vmm-swap policies are doing a good job at deciding when to enable vmm-swap. kawasin@google.com sstan@google.com An lower bound estimate of the average number of pages resident on disk over the duration of the vmm-swap period. Even if the actual page size is not 4KiB, it is recalculated to be the number of 4KiB pages. This is sent when vmm-swap is disabled. kawasin@google.com sstan@google.com Tracks events that would cause vmm-swap to be disabled. This is sent regardless of whether or not vmm-swap was actually active - i.e. alongside both ".ActiveAfterEnableDuration" and ".InactiveNoEnableDuration". Each event type is broken down into two enum values - one for the inactive and one for the active case. kawasin@google.com sstan@google.com The duration how long it was spent waiting to enable vmm-swap since it becomes swappable-idle. This is sent with ".ActiveAfterEnableDuration" metrics when vmm-swap is disabled. kawasin@google.com sstan@google.com The duration how long it was spend without vmm-swap enabled and it exits swappable-idle. This is sent when vmm-swap is disabled. If reported values are mostly long, it indicates that the policies are missing chances to enable vmm-swap. kawasin@google.com sstan@google.com The minimum number of pages resident on disk any given point during the vmm-swap period. Even if the actual page size is not 4KiB, it is recalculated to be the number of 4KiB pages. This is sent when vmm-swap is disabled. kawasin@google.com sstan@google.com The average duration of each page of the guest memory lives in the swap file. We expect most cold pages live in the swap file for a long time and hot pages are not swapped out but kept in the memory. The durations are measured every 10 minutes to estimate the average duration. This is sent when vmm-swap is disabled. kawasin@google.com sstan@google.com Tracks the policy decision made when deciding how to handle a swap enable dbus request. Indicates if a request was accepted or why it was rejected. Each decision result is further broken down into whether it occured while handling an initial enable request or a maintenance request. kawasin@google.com sstan@google.com Sends the vmm-swap state (enabled or disabled) every 10 minutes while the vm is swappable-idle. Vmm-swap may not be enabled by policies to protect disk. This metrics indicates what percentage of time in the swappable-idle state is spent with vmm-swap enabled and how well the policies works. acondor@google.com clank-performance-team@google.com The private memory footprint of a renderer process hosting {1pNtpState}. Recorded during periodic process memory dumps. acondor@google.com clank-performance-team@google.com The private memory footprint of the {Process} when {1pNtpState}. Recorded during periodic process memory dumps. thiabaud@google.com lizeb@google.com Whether all pages in the renderer are frozen. Recorded right before we begin self-compaction. thiabaud@google.com lizeb@google.com Whether we were able to read /proc/self/maps successfully. If self-compaction is not enabled, this will always record as success. Recorded right before we begin self-compaction. thiabaud@google.com lizeb@google.com How long self-compaction took. Recorded after self-compaction has finished. thiabaud@google.com lizeb@google.com Time since the last time we cancelled self-compaction. Recorded after we finish self compaction. thiabaud@google.com lizeb@google.com The difference in the chosen metric, taken from /proc/self/smaps_rollup at the two specified times. "Increase" metrics are recorded when the latter snapshot is higher, "Decrease" metrics when the latter snapshot is lower. Either a metric is recorded for all variants, or no metric is recorded. thiabaud@google.com lizeb@google.com The amount of memory used, taken from /proc/self/smaps_rollup. Recorded directly before self-compaction, directly after, and after the specified delays. Either a metric is recorded for all variants, or no metric is. erikchen@chromium.org ssid@chromium.org A rough estimate of the private memory footprint of the {UtilityProcessType} process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This memory footprint metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org An amount of private memory of the {UtilityProcessType} process placed in swap (VmSwap). Available on Android, Linux and ChromeOS. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note: Histogram data may be missing for mid-2020 due to expiry. fdoray@chromium.org The size of the resident memory in a {UtilityProcessType} process. This is influenced by factors we control (e.g. memory that is not accessed can be swapped) and factors we don't control (e.g. an unrelated process using a lot of memory can force memory in our process to be swapped). Recorded on Windows/Linux/ChromeOS/Android. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. This resident memory metric cannot be compared across platforms because each platform relies on platform-level APIs for accounting. As such, though this attempts to measure private memory footprint as best as possible, it does not measure the same thing on each platform. We have not found a good way to compare any system level memory metric across platforms due to the different nature of memory management on each platform. erikchen@chromium.org ssid@chromium.org A rough estimate of the shared memory footprint of the {UtilityProcessType} process. Recorded at Poisson sampled time intervals with a mean of 5 minutes on Android and 30 minutes on other platforms. Note #1: Histogram data may be missing between M77 to M87 due to expiry. Note #2: Incorrect metrics were reported for M140; there was no actual regression. Details can be found at crbug.com/450560777 and crrev.com/c/7041925. ssid@chromium.org chrome-metrics-team@google.com Whether Chrome is running in low ram mode. This histogram is reported on every upload by Android devices. A device is considered low-RAM if it has 512MiB of RAM or lower (see SysUtils.detectLowEndDevice()). thiabaud@google.com PSS metric for the process. Recorded on Android, Linux, and ChromeOS only. The value "0" is expected on kernels that don't support /proc/self/smaps_rollup. thiabaud@google.com Swap PSS metric for the process. Recorded on Android, Linux, and ChromeOS only.