gdeepti@chromium.org ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@chromium.org Number of bytes requested in array buffer allocations greater than one megabyte. gdeepti@chromium.org ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@chromium.org Array buffer sizes for which V8 failed to allocate memory. ecmziegler@chromium.org wasm-runtime@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. emaxx@google.com 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. emaxx@google.com v8-security@google.com The result of trying to pkey_mprotect the ThreadIsolationData at runtime. This metric is recorded once at renderer startup when the ThreadIsolatedAllocator is initialized. marja@chromium.org v8-runtime@chromium.org Reason code data has been rejected when attempting to deserialize. leszeks@chromium.org v8-runtime@google.com 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. marja@chromium.org v8-runtime@google.com 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) {Reason}. 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 {CacheBehavior}. 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 v8-runtime@google.com Time spent {Action} 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. marja@chromium.org v8-runtime@google.com Aggregated time spent in compiling on the {Thread} thread until the page turned interactive. Emitted when the page turns interactive. Includes samples only from clients with a high-resolution clock. olivf@chromium.org v8-runtime@google.com Records the maximum depth of an ES module import graph. Recorded upon successful module graph instantiation in V8. olivf@chromium.org v8-runtime@google.com Records the total number of ES modules instantiated in a top-level module import graph. Recorded upon successful module graph instantiation in V8. 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. marja@chromium.org v8-runtime@google.com Aggregated time spent in executing JavaScript (all compiler tiers) until the page turned interactive. Emitted when the page turns interactive. Includes samples only from clients with a high-resolution clock. mlippautz@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. omerkatz@chromium.org v8-memory-sheriffs@google.com The percentage of managed C++ memory that was freed after a {Priority} garbage collection of the {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 survived after a {Priority} young generation garbage collection of the JavaScript heap. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Overall duration of a {Priority} garbage collection of the {Heap}, normalized by the wall time since the last mark compact cycle. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Overall duration of a {Priority} garbage collection of the {Heap} on the main thread only, normalized by the wall time since the last mark compact cycle. This histogram ignores concurrent garbage collection. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Amount of {Scope} consumed memory right before a {Priority} full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Allocation limit on {Scope} consumed memory used before a {Priority} full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Hard cap on allocation limit for {Scope} consumed memory used before a {Priority} 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 speed at which a {Priority} garbage collection of the {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 a {Priority} garbage collection of the {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 {Priority} 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 {Priority} young generation garbage collection of the JavaScript heap reclaims unused memory. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com The external memory size right before a {Priority} full garbage collection of the unified heap. Reported at the end of the garbage collection cycle. hpayer@chromium.org mlippautz@chromium.org v8-memory-sheriffs@google.com The number of JSGlobalProxy objects found during a full garbage collection. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on compaction during a whole {Priority} garbage collection of the {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 {Priority} garbage collection of the {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 {Priority} garbage collection of the {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 {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of a whole {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. thiabaud@google.com etiennep@chromium.org v8-memory-sheriffs@google.com Same as "V8.GC.Cycle{Priority}.Full", but split on whether we are currently in input-handling mode. omerkatz@chromium.org v8-memory-sheriffs@google.com Overall duration of compaction on the main thread during the atomic pause of a {Priority} garbage collection of the {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 marking on the main thread during the atomic pause of a {Priority} garbage collection of the {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 sweeping on the main thread during the atomic pasue of a {Priority} garbage collection of the {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 weakness handling on the main thread during the atomic pause of a {Priority} garbage collection of the {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 main thread duration of the atomic pause of a {Priority} garbage collection of the {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. omerkatz@chromium.org v8-memory-sheriffs@google.com Time spent on compaction on the main thread during a whole {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Wall time duration of incremental marking during a {Priority} 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 {Priority} full garbage collection of the {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 {Priority} full garbage collection of the {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 {Priority} garbage collection of the {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 {Priority} garbage collection of the {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 {Priority} garbage collection of the {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 {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. thiabaud@google.com etiennep@chromium.org v8-memory-sheriffs@google.com Same as "V8.GC.Cycle{Priority}.MainThread.Full", but split on whether we are currently in input-handling mode. nikolaos@chromium.org v8-memory-sheriffs@google.com Main-thread only duration of a {Priority} 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 {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Amount of used memory after a {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. omerkatz@chromium.org v8-memory-sheriffs@google.com Amount of used memory before a {Priority} garbage collection of the {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 {Priority} garbage collection of the {Heap}. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Reason a {Priority} full garbage collection was started in V8. Reported at the end of the garbage collection cycle. thiabaud@google.com etiennep@chromium.org v8-memory-sheriffs@google.com Same as "V8.GC.Cycle{Priority}.Reason.Full", but split on whether we are currently in input-handling mode. nikolaos@chromium.org v8-memory-sheriffs@google.com Reason a {Priority} young generation garbage collection was started in V8. Reported at the end of the garbage collection cycle. etiennep@chromium.org v8-memory-sheriffs@google.com Time between the start of a {Priority} full garbage collection and the end of previous full cycle. Reported at the end of the garbage collection cycle. nikolaos@chromium.org v8-memory-sheriffs@google.com Overall duration of a {Priority} 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. omerkatz@chromium.org v8-memory-sheriffs@google.com Duration of individual incremental marking steps on the main thread during a garbage collection of the {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 {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 worker isolates and 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. 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. 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 olivf@chromium.org The number of in-use entries in a JSDispatchTable. JSFunctions reference their code through an entry in the JSDispatchTable. This provides fine-grained CFI for JavaScript function calls and facilitates tier-up and tier-down of compiled functions. This histogram records the number of active entries in the JSDispatchTable during garbage collection. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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. nidhijaju@chromium.org chrome-loading@google.com Time spent on creating a new v8 context with the window wrapper, reported immediately after creation. nidhijaju@chromium.org chrome-loading@google.com Time spent on initializing the local window wrapper, reported immediately after initialization. This includes creating the v8 context with the window wrapper and updating the document properties. leszeks@chromium.org v8-runtime@chromium.org {Phase}. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. hpayer@chromium.org The total size of committed memory used by V8 after each GC in KB. {V8SpecialApps} jgruber@chromium.org pthier@chromium.org The number of backtracks performed in a single regexp execution. mlippautz@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. mlippautz@chromium.org ishell@chromium.org The number of in-use entries in a CppHeapPointerTable. When the V8 Sandbox is enabled, objects in the Cpp Heap (such as C++ DOM objects) that are wrapped by a V8 object are referenced through a pointer table indirection (via the CppHeapPointerTable) to ensure memory-safe access to them. This histogram records the number of active entries in the per-Isolate CppHeapPointerTable during garbage collection. mlippautz@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. mlippautz@chromium.org ishell@chromium.org The number of in-use entries in a TrustedPointerTable. When the V8 Sandbox is enabled, "trusted" V8 objects are referenced from inside the sandbox through a pointer table indirection (via the TrustedPointerTable) to ensure memory-safe access to them. This histogram records the number of active entries in the per-Isolate TrustedPointerTable during garbage collection. mlippautz@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. mlippautz@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. jgruber@chromium.org leszeks@chromium.org v8-runtime@google.com Time spent deserializing the {Part} 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. dmercadier@chromium.org v8-runtime@chromium.org {Phase} 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. dmercadier@chromium.org v8-runtime@chromium.org Total time spent on a {Thread} thread during TurboFan optimization. Recorded on each regular optimization of a function. This histogram only records metrics on machines with high-resolution clocks. dmercadier@chromium.org v8-runtime@chromium.org {Phase}. 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. ecmziegler@chromium.org wasm-runtime@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. ecmziegler@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. ecmziegler@chromium.org wasm-runtime@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. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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. {V8WasmSeparateAsmAndWasm} clemensb@chromium.org ecmziegler@chromium.org wasm-runtime@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-runtime@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 clemensb@chromium.org wasm-runtime@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 clemensb@chromium.org wasm-runtime@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. {V8WasmSeparateAsmAndWasm} ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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. mliedtke@chromium.org dlehmann@chromium.org ecmziegler@chromium.org wasm-runtime@google.com The number of deopts executed by the wasm engine so far. As a baseline, a 0 sample is added for each function that gets tiered-up with Turbofan if the function contains at least one deopt-point, meaning functions which can never deopt (or weren't tiered up), do not appear in this histogram at all. At each deopt a sample is added, so if there were 2 deopts in total, there will be one sample for 0 (for the initial tier-up), one for 1 and one for 2 deopts. If an optimized function is served from cache, it does not add a new 0 sample. mliedtke@chromium.org dlehmann@chromium.org ecmziegler@chromium.org wasm-runtime@google.com The number of deopts executed per function (meaning each function has a separate counter). Similarly to V8.WasmDeoptsExecutedCount, this will add a sample for each deoptimization of each function. clemensb@chromium.org ecmziegler@chromium.org wasm-runtime@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. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@google.com The amount of metadata in KiB used by the overall WebAssembly engine. Recorded after each full GC. clemensb@chromium.org wasm-runtime@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 clemensb@chromium.org wasm-runtime@google.com Function count per WebAssembly module. Recorded for each WebAssembly module which is decoded for validation, compilation, or deserialization. {V8WasmSeparateAsmAndWasm} ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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. {V8WasmSeparateAsmAndWasm} ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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. {V8WasmSeparateAsmAndWasm} clemensb@chromium.org ecmziegler@chromium.org wasm-runtime@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. ecmziegler@chromium.org wasm-runtime@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-runtime@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 clemensb@chromium.org wasm-runtime@google.com The amount of committed code space in KiB used by individual WebAssembly modules. Recorded for each live module after each full GC. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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 clemensb@chromium.org wasm-runtime@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 clemensb@chromium.org wasm-runtime@google.com The amount of metadata in KiB used by individual WebAssembly modules. Recorded for each live module after each full GC. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@google.com Number of code GCs triggered per WebAssembly module. Recorded after each code GC. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@google.com The number of code spaces (i.e. individual reservations) of a WebAssembly module. Recorded on every code space allocation. ecmziegler@chromium.org wasm-runtime@google.com Size of the wire bytes of a WebAssembly module. Recorded for each WebAssembly module which is decoded for validation, compilation, or deserialization. {V8WasmSeparateAsmAndWasm} clemensb@chromium.org ecmziegler@chromium.org wasm-runtime@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-runtime@google.com Number of WebAssembly native modules live in an isolate. Recorded whenever a new native module is created. clemensb@chromium.org ecmziegler@chromium.org wasm-runtime@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). ecmziegler@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. ecmziegler@chromium.org clemensb@chromium.org wasm-runtime@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.