gdeepti@chromium.org ecmziegler@chromium.org clemensb@chromium.org Number of bytes requested in array buffer allocations greater than one megabyte. gdeepti@chromium.org ecmziegler@chromium.org clemensb@chromium.org Array buffer sizes for which V8 failed to allocate memory. ahaas@chromium.org ecmziegler@chromium.org wasm-v8@google.com Counter of succeeded and failed asm.js instantiations with the asm.js pipeline. Success means that the asm.js pipeline is used to execute the asm.js module. Failure means that the asm.js module gets executed with the normal JavaScript pipeline. Reasons for failed instantiations can be that the asm.js module gets instantiated with an invalid memory type like a WebAssembly memory. Recorded after each attempt to instantiate asm.js module with the asm.js pipeline. sroettger@google.com v8-security@google.com Whether there's a mismatch between the maximum page size we assume at compile time and the page size we assume at runtime. This metric is recorded once at renderer startup when the ThreadIsolatedAllocator is initialized. yangguo@chromium.org Reason code data has been rejected when attempting to deserialize. delphick@chromium.org Time spent collecting source positions to generate stack traces. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. yangguo@chromium.org Time spent compiling a script that may be subject to caching. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. jgruber@chromium.org leszeks@chromium.org Time spent deserializing code, used by V8 code caching. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. yangguo@chromium.org Time spent in V8 compiler (full codegen) for eval. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. hablich@chromium.org Aggregated time spent compiling functions lazily during a single script execution. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. yangguo@chromium.org Time spent in V8 compiler (full codegen) excluding parser. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com The cache behaviour of compiling a V8 script, including whether we produced or consumed a code cache, whether we hit V8's isolate's cache, and if we didn't use the code cache, the reason why not. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing/caching). Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org rmcilroy@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing) on a background thread. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script when the 'compilation' is deserializing it from the code cache. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing/caching) when the compilation tried to deserialize it from the code cache, but failed. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing/caching) in the case where the V8 isolate's compilation cache is hit. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing) when the cache is too cold to use. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing) when the script is an inline script. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing) when we do not want to cache it. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing) when the script is too small to be cached. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in compiling a script (incl. parsing) and serializing it for the code cache. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. leszeks@chromium.org v8-runtime@google.com Total time spent in finalizing a script that was streaming compiled. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. jgruber@chromium.org leszeks@chromium.org Time spent serializing code, used by V8 code caching. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. bmeurer@chromium.org szuend@chromium.org chrome-devtools@google.com Duration beginning when V8 stops execution due to a breakpoint/exception until the "Debugger.paused" CDP event is sent by the V8 inspector. The event is recorded when all the event data was collected and processed, but before the event is serialized and put on the wire. hablich@chromium.org The amount of JavaScript errors thrown by V8 per context. It does not count custom errors and ignores catched errors thrown by V8. This is collected after the context is detached. cbruni@chromium.org v8-runtime@google.com Time spent in JavaScript Execution, including runtime calls, and lazy compilation. This histogram excludes time spent in embedder callbacks. saelo@chromium.org ishell@chromium.org The outcome of external pointer table compaction. External pointer table compaction may only succeed partially or fail entirely if the application allocates lots of external pointer table entries while the table is being compacted. This histogram records this outcome at the end of a table-compacting GC. The frequency of such failures influences the heuristics used to decide when to compact the table, and to some degree also the compaction algorithm itself. nikolaos@chromium.org v8-memory-sheriffs@google.com The percentage of managed JavaScript memory that has been collected by a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com The percentage of managed C++ memory that has been collected by a garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com The percentage of managed JavaScript memory that has been collected by a young generation garbage collection of the JavaScript heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com The speed at which a full garbage collection of the unified heap reclaims unused memory. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com The speed at which garbage collection of the managed C++ heap reclaims unused memory. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com The speed at which a full garbage collection of the unified heap reclaims unused memory on the main thread only. This histogram ignores concurrent garbage collection. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com The speed at which garbage collection of the managed C++ heap reclaims unused memory on the main thread only. This histogram ignores concurrent garbage collection. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com The speed at which a young generation garbage collection of the JavaScript heap reclaims unused memory on the main thread only. This histogram ignores concurrent garbage collection. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com The speed at which a young generation garbage collection of the JavaScript heap reclaims unused memory. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on compaction during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on compaction during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on marking during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on marking during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on sweeping during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on sweeping during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on weakness handling during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on weakness handling during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Main-thread only duration of a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall main thread duration of the atomic pause of a garbage collection of the unified heap. There is only a single atomic pause event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of compaction on the main thread during the atomic pause of a garbage collection of the unified heap. There is only a single atomic pause compaction event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of compaction on the main thread during the atomic pause of a garbage collection of the managed C++ heap. There is only a single atomic pause compaction event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall main thread duration of the atomic pause of a garbage collection of the managed C++ heap. There is only a single atomic pause event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of marking on the main thread during the atomic pause of a garbage collection of the unified heap. There is only a single atomic pause marking event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of marking on the main thread during the atomic pause of a garbage collection of the managed C++ heap. There is only a single atomic pause marking event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of sweeping on the main thread during the atomic pasue of a garbage collection of the unified heap. There is only a single atomic pause sweeping event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of sweeping on the main thread during the atomic pasue of a garbage collection of the managed C++ heap. There is only a single atomic pause sweeping event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of weakness handling on the main thread during the atomic pause of a garbage collection of the unified heap. There is only a single atomic pause weakness handling event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of weakness handling on the main thread during the atomic pause of a garbage collection of the managed C++ heap. There is only a single atomic pause weakness handling event per cycle but it may cover several sub-events. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on compaction on the main thread during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on compaction on the main thread during a whole garbage collection of the cpp heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Main thread only duration of a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of incremental marking steps on the main thread during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of incremental marking steps on the main thread during a full garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of incremental sweeping steps on the main thread during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of incremental sweeping steps on the main thread during a full garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on marking on the main thread during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on marking on the main thread during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on sweeping on the main thread during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on sweeping on the main thread during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Time spent on weakness handling on the main thread during a full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on weakness handling on the main thread during a whole garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Main-thread only duration of a young generation garbage collection of the JavaScript heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Amount of allocated memory freed by a garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Amount of used memory after a garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Amount of used memory before a garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Amount of used memory freed by a garbage collection of the managed C++ heap. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Reason a full garbage collection was started in V8. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Reason a young generation garbage collection was started in V8. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of a young generation garbage collection of the JavaScript heap. Reported at the end of the garbage collection cycle. mlippautz@chromium.org v8-memory-sheriffs@google.com Time spent in the atomic pause of a {Mode} {Incrementality} full garbage collection for a V8 Isolate running in {Visibility}. Recorded at the end of the garbage collection. nikolaos@chromium.org v8-memory-sheriffs@google.com Duration of individual incremental marking steps on the main thread during a garbage collection of the unified heap. omerkatz@chromium.org v8-memory-sheriffs@google.com Duration of individual incremental marking steps on the main thread during a garbage collection of the managed C++ heap. nikolaos@chromium.org v8-memory-sheriffs@google.com Duration of individual incremental sweeping steps on the main thread during a garbage collection of the unified heap. omerkatz@chromium.org v8-memory-sheriffs@google.com Duration of individual incremental sweeping steps on the main thread during a garbage collection of the managed C++ heap. dinfuehr@chromium.org v8-memory-sheriffs@google.com Time between requesting GC from background thread and actually starting collection on main thread. This is reported each time a background thread requests a GC. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. dinfuehr@chromium.org v8-memory-sheriffs@google.com Time spent in stopping other threads to reach a safepoint. This is reported each time a safepoint is reached. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. mlippautz@chromium.org hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in the clearing phase of incremental latency-optimized Mark-Compact GC. mlippautz@chromium.org hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in the epilogue of incremental latency-optimized Mark-Compact GC. mlippautz@chromium.org hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in the finish phase of incremental latency-optimized Mark-Compact GC. mlippautz@chromium.org hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in the prologue of incremental latency-optimized Mark-Compact GC. hpayer@chromium.org mlippautz@chromium.org v8-memory-sheriffs@google.com Time spent doing incremental marking steps during garbage collection. Recorded at the end of each step. mlippautz@chromium.org v8-memory-sheriffs@google.com Reason an incremental marking was started in V8. hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in starting incremental marking. mlippautz@chromium.org v8-memory-sheriffs@google.com The total time spent in incremental marking steps in one GC cycle. It is only recorded if the time is non-zero. mlippautz@chromium.org v8-memory-sheriffs@google.com Reason a mark-compact garbage collection was started in V8. mlippautz@chromium.org v8-memory-sheriffs@google.com Sum of all durations of all marking phases (incremental and non-incremental) within one V8 garbage collection cycle. Reported once per garbage collection at the end. Removed 02/2022. hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in scavenging phase of GC in a background isolate. Removed 02/2022. Superseded by V8.GC.Cycle.Reason.Young. mlippautz@chromium.org v8-memory-sheriffs@google.com Reason a scavenge garbage collection was started in V8. Removed 02/2022. hpayer@chromium.org v8-memory-sheriffs@google.com Time spent in scavenging phase of GC in a foreground isolate. oth@chromium.org Results from snapshot loading. oth@chromium.org Results from opening V8 snapshot files. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org Liftoff (V8's baseline compiler for WebAssembly) bails out if it hits the first unsupported feature in a function. The function is recompiled with TurboFan then. This histogram records the bailout reason (or success) per WebAssembly function compilation in Liftoff. hpayer@chromium.org External memory fragmentation in the code space after each GC in percent. hpayer@chromium.org External memory fragmentation in the large object space after each GC in percent. hpayer@chromium.org External memory fragmentation in the map space after each GC in percent. hpayer@chromium.org External memory fragmentation in the old space after each GC in percent. hpayer@chromium.org The size of committed memory in the code space after each GC in KB. hpayer@chromium.org The size of committed memory in the map space after each GC in KB. hpayer@chromium.org The maximum size of committed memory used by V8 after each GC in KB. hpayer@chromium.org The total size of committed memory used by V8 after each GC in KB. chikamune@chromium.org chrome-worker@google.com Time spent serializing and persisting code (mojo call) for V8 code caching. Recorded when ProduceCacheInternal() is called. Only recorded when producing a code cache is required. jgruber@chromium.org pthier@chromium.org The number of backtracks performed in a single regexp execution. saelo@chromium.org ishell@chromium.org The number of in-use entries in a CodePointerTable. When the V8 Sandbox is enabled, code pointers are stored in a CodePointerTable instead of on the V8 heap to ensure that they cannot be manipulated by an attacker. This histogram records the number of active entries in the CodePointerTable during garbage collection. saelo@chromium.org ishell@chromium.org The number of in-use external pointers in an Isolate's ExternalPointerTable. When the V8 Sandbox is enabled, objects located outside of the sandbox are referenced through a per-Isolate ExternalPointerTable to ensure memory-safe access to them. This histogram records the number of active external pointers in a single table, which is determined by counting the number of alive entries during garbage collection of an ExternalPointerTable. saelo@chromium.org ishell@chromium.org Mode of operation of V8's sandbox. By default, the V8 sandbox is fully backed by a large virtual address space reservation, ensuring that only V8-related objects are located inside the sandbox. In that case, the sandbox is configured securely. However, when it is not possible to reserve a sufficient amount of virtual address space during initialization (e.g. due to memory or virtual address space constraints), the sandbox will instead use a fallback mode where only a part of the sandbox's address space is actually reserved. In that case, unrelated memory mappings may end up inside the sandbox though, where they could be corrupted by an attacker. As such, this mode is considered insecure. Recorded as enum value during initialization of V8. saelo@chromium.org ishell@chromium.org Size of the virtual address space reservation backing the V8 sandbox, in GB. This value is typically larger than the size of the sandbox as it includes the surrounding guard regions. However, in the case of a partially-reserved (i.e. insecure) sandbox, this value will be smaller than the sandbox size. Recorded during initialization of V8. gdeepti@chromium.org ulan@chromium.org Number of megabytes requested in shared array buffer allocations. jgruber@chromium.org leszeks@chromium.org Time spent deserializing the context snapshot. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. jgruber@chromium.org leszeks@chromium.org Time spent deserializing the isolate snapshot. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. jgruber@chromium.org leszeks@chromium.org Time spent deserializing the read-only snapshot. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. szuend@chromium.org bmeurer@chromium.org Each time a script is parsed we report how the source map for that script is specified. This histogram does not care whether a source map is actually publicly available or if it's specified inline as a data URL. tebbi@chromium.org mslekova@chromium.org Number of ticks (in 1000s of ticks) from starting optimizing to installing the code object. Recorded on each regular optimization of a function. Similar to V8.TurboFanOptimizeTotalTime, but instead of counting time, we count a deterministic number of ticks sprinkled throughout the Turbofan compiler. tebbi@chromium.org mslekova@chromium.org Total time from starting optimizing to installing the code object. Recorded on each regular, concurrent optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Time spent in the execution phase of TurboFan optimization. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Time spent in the finalization phase of TurboFan optimization. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Time spent in the execution phase of TurboFan optimization for On Stack Replacement (OSR). Recorded on each optimization for on-stack replacement of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Time spent in the finalization phase of TurboFan optimization for On Stack Replacement (OSR). Recorded on each optimization for on-stack replacement of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Time spent in the preparation phase of TurboFan optimization for On Stack Replacement (OSR). Recorded on each optimization for on-stack replacement of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Total time from starting optimizing for On Stack Replacement (OSR) to installing the code object. Recorded on each optimization for on-stack replacement of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Total time from starting optimizing to installing the code object. Recorded on each regular, non-concurrent optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Time spent in the preparation phase of TurboFan optimization. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Total time spent on a background thread during TurboFan optimization. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Total time spent on the main thread during TurboFan optimization. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. tebbi@chromium.org mslekova@chromium.org Total time from starting optimizing to installing the code object. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. chikamune@chromium.org sisidovski@chromium.org hiroshige@chromium.org kouhei@chromium.org Report true when an unhandled exception is reported in the main thread, which may happen when the code has no appropriate exception handling in the main thread. The false value is never reported. This histogram is supposed to be used in A/B testing to check if unhandled exception count is different across experiment groups by counting the true values. chikamune@chromium.org sisidovski@chromium.org hiroshige@chromium.org kouhei@chromium.org Report true when an unhandled exception is reported in the worker, which may happen when the code has no appropriate exception handling in the worker. The false value is never reported. This histogram is supposed to be used in A/B testing to check if unhandled exception count is different across experiment groups by counting the true values. ahaas@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of times a WebAssembly module being added to the browser cache. With dynamic tiering, caching is triggered repeatedly whenever the amount of generated optimized code reaches a threshold. Recorded every time a new version of the WebAssembly module is being added to the cache, and also when the module is compiled initially. thibaudm@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of exceptions caught so far in an isolate, recorded on each caught exception. ahaas@chromium.org clemensb@chromium.org wasm-runtime@google.com The result of a Wasm code cache lookup. Recorded once per Wasm streaming compilation at the time where we try to get the compiled Wasm module from the code cache. ahaas@chromium.org ecmziegler@chromium.org wasm-v8@google.com WebAssembly JS API function that triggers compilation. Recorded when WebAssembly compilation gets triggered, independently of the compilation results, i.e. whether compilation succeeds or fails. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time from finishing compilation of a WebAssembly module until downloading the module finishes with streaming compilation. Recorded when streaming compilation finishes and the compilation of the WebAssembly module finished before the download. If the download finishes first, then the histogram V8.WasmStreamingUntilCompilationFinishedMilliSeconds is recorded. ahaas@chromium.org ecmziegler@chromium.org wasm-v8@google.com After deserialization, all functions that were not in the serialized module are compiled with the baseline compiler. This metric measures the time spent by the baseline compiler on compiling missing functions. Recorded after the baseline compilation of the missing functions finishes. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Time to compile a WebAssembly function. Recorded on each compilation of a single function, either synchronous, asynchronous, or lazily. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time to compile a huge WebAssembly function. A function is considered huge if it is larger than 100kB. Recorded on each compilation of such a function, either synchronous, asynchronous, or lazily. clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Peak memory used to compile a huge WebAssembly function. A function is considered huge if it is larger than 100kB. Recorded for each TurboFan compilation of such a function. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Time to asynchronously compile a WebAssembly module (using the 'WebAssembly.compile' API). Recorded on each asynchronous WebAssembly compilation, but only if a high-resolution clock is available. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Time to compile a WebAssembly module. Recorded on each synchronous WebAssembly compilation. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Time to asynchronously compile a WebAssembly module using streaming compilation (via the 'WebAssembly.compileStreaming' API). Recorded on each streaming WebAssembly compilation, but only if a high-resolution clock is available. Note that compilation speed is often limited by the network speed, which is also reflected in this metric. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time to deserialize a WebAssembly module when the WebAssembly module is loaded from the cache. Recorded whenever a WebAssembly module gets deserialized during streaming compilation. bbudge@chromium.org clemensb@chromium.org adamk@chromium.org wasm-v8@google.com Time to asynchronously compile or deserialize a WebAssembly module during streaming compilation (via the 'WebAssembly.compileStreaming' API). Recorded on each streaming WebAssembly compilation or deserialization from the cache, but only if a high-resolution clock is available. Note that compilation speed is often limited by the network speed, which is also reflected in this metric. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Function count per WebAssembly module. Recorded for each WebAssembly module which is decoded for validation, compilation, or deserialization. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Size of a huge WebAssembly function in bytes. A function is considered huge if it is larger than 100kB. Recorded on each compilation of a single function, either synchronous, asynchronous, or lazily. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Time to instantiate a WebAssembly module. Recorded on each instantiation of a WebAssembly module. Warning: This metric may include reports from clients with low-resolution clocks (i.e. on Windows, ref. |TimeTicks::IsHighResolution()|). Such reports will cause this metric to have an abnormal distribution. When considering revising this histogram, see UMA_HISTOGRAM_CUSTOM_MICROSECONDS_TIMES for the solution. clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time spend for lazily compiling WebAssembly functions. Recorded on each lazy compilation event (which typically compiles one function). This histogram only records metrics on machines with high-resolution clocks. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Maximum time spent on the main thread on compiling a single WebAssembly function with lazy compilation in the first 120 seconds after the first instantiation of a WebAssembly module. Recorded 120 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Maximum time spent on the main thread on compiling a single WebAssembly function with lazy compilation in the first 20 seconds after the first instantiation of a WebAssembly module. Recorded 20 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Maximum time spent on the main thread on compiling a single WebAssembly function with lazy compilation in the first 5 seconds after the first instantiation of a WebAssembly module. Recorded 5 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Maximum time spent on the main thread on compiling a single WebAssembly function with lazy compilation in the first 60 seconds after the first instantiation of a WebAssembly module. Recorded 60 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ecmziegler@chromium.org adamk@chromium.org ahaas@chromium.org wasm-v8@google.com The result of attempts to allocate WebAssembly.Memory buffers. Recorded on each attempt to allocate a WebAssembly.Memory buffer. clemensb@chromium.org jkummerow@chromium.org ecmziegler@chromium.org wasm-v8@google.com Whether the system supports memory protection keys in userspace (MPK / PKU / PKEY). This is determined once per process and recorded once per isolate during isolate creation (startup). As we use a Linux-specific API for PKUs, this value is only recorded on 64-bit Linux machines. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com The amount of committed code space in MiB used by individual WebAssembly modules. Recorded for each live module after each full GC. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com The percentage of WebAssembly code freed by garbage collection (ratio of total freed code to total generated code so far). Recorded for each live module after each full GC. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Number of code GCs triggered per WebAssembly module. Recorded after each code GC. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com The number of code spaces (i.e. individual reservations) of a WebAssembly module. Recorded on every code space allocation. ecmziegler@chromium.org adamk@chromium.org ahaas@chromium.org wasm-v8@google.com Size of the wire bytes of a WebAssembly module. Recorded for each WebAssembly module which is decoded for validation, compilation, or deserialization. clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of WebAssembly native modules live in a Wasm engine (typically per process). Recorded whenever a new native module is created. clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of WebAssembly native modules live in an isolate. Recorded whenever a new native module is created. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of functions that get compiled lazily in 120 seconds after the first instantiation of a WebAssembly module. Recorded 120 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of functions that get compiled lazily in 20 seconds after the first instantiation of a WebAssembly module. Recorded 20 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of functions that get compiled lazily in 5 seconds after the first instantiation of a WebAssembly module. Recorded 5 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of functions that get compiled lazily in 60 seconds after the first instantiation of a WebAssembly module. Recorded 60 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. thibaudm@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of exceptions rethrown so far in an isolate, recorded on each rethrown exception. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time to serialize a WebAssembly module for storing it in the cache. Recorded on each serialization, which happens after top-tier compilation finished, or when a new chunk of functions was compiled (with dynamic tiering). ahaas@chromium.org clemensb@chromium.org wasm-runtime@google.com Classification of the argument to the streaming WebAssembly APIs (WebAssembly.compileStreaming and WebAssembly.instantiateStreaming). Recorded on each invocation of this API. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time from finishing downloading a WebAssembly module until streaming compilation finishes. Recorded when streaming compilation finishes and the download of the WebAssembly module finished before compilation. If compilation finishes first, then the histogram V8.WasmCompilationUntilStreamFinishedMilliSeconds is recorded. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Total time spent on the main thread on compiling WebAssembly functions with lazy compilation in the first 120 seconds after the first instantiation of a WebAssembly module. Recorded 120 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Total time spent on the main thread on compiling WebAssembly functions with lazy compilation in the first 20 seconds after the first instantiation of a WebAssembly module. Recorded 20 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Total time spent on the main thread on compiling WebAssembly functions with lazy compilation in the first 5 seconds after the first instantiation of a WebAssembly module. Recorded 5 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. ahaas@chromium.org clemensb@chromium.org ecmziegler@chromium.org wasm-v8@google.com Total time spent on the main thread on compiling WebAssembly functions with lazy compilation in the first 60 seconds after the first instantiation of a WebAssembly module. Recorded 60 seconds after calling the start function of the WebAssembly module during the first instantiation of a WebAssembly module. thibaudm@chromium.org ecmziegler@chromium.org wasm-v8@google.com Number of exceptions thrown so far in an isolate, recorded on each thrown exception. ecmziegler@chromium.org adamk@chromium.org clemensb@chromium.org wasm-v8@google.com Time to tier-up a WebAssembly module, i.e. the time between baseline compilation finishes and top-tier compilation finishes. Recorded whenever an asynchronously compiled module finishes top-tier compilation, but only if a high-resolution clock is available. thibaudm@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time since the last time an exception was caught in WebAssembly, recorded when the next exception is caught (per isolate). thibaudm@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time since the last time an exception was rethrown in WebAssembly, recorded when the next exception is rethrown (per isolate). thibaudm@chromium.org ecmziegler@chromium.org wasm-v8@google.com Time since the last time an exception was thrown in WebAssembly, recorded when the next exception is thrown (per isolate).