Could we also add a new histogram / counter to track what percentage of pages are failing validation. At your discretion how to set it up, but perhaps broken out by module size.

Adding some folks who will care we're adding more uma.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/c7ec5bf414023242e03a5118c808844164e86542

commit c7ec5bf414023242e03a5118c808844164e86542
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 24 18:46:55 2017

Separate module instantiate counter for asm and wasm.

Currently, v8 uses the same flag to collect time for instantiating wasm modules
from js asm and wasm. This separates the v8 counter into two separate counters,
and then uses the appropriate counter when instantiating a module.

BUG= chromium:704922 
R=aseemgarg@chromium.org,bradnelson@chromium.org,bbudge@chromium.org

Review-Url: https://codereview.chromium.org/2772773004
Cr-Commit-Position: refs/heads/master@{#44122}

[modify] https://crrev.com/c7ec5bf414023242e03a5118c808844164e86542/src/counters.h
[modify] https://crrev.com/c7ec5bf414023242e03a5118c808844164e86542/src/wasm/wasm-module.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/ba40bf7a42324d3e58a013e41683ee207f392a0b

commit ba40bf7a42324d3e58a013e41683ee207f392a0b
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 24 21:27:36 2017

Separate module compile counter for asm and wasm.

Currently, v8 uses the same flag to collect time for compiling wasm modules from js asm and wasm. This separates the v8 counter into two separate counters, and then uses the appropriate counter when compiling a module.

Note: This CL doesn't separate the corresponding Chromium counter. Rather that is intenionally being delayed until v8 code has separated all appropriate counters for js asm and wasm. That way, the installation into chrome can be done at once.

BUG= chromium:704922 
R=bradnelson@chromium.org,bbudge@chromium.org

Review-Url: https://codereview.chromium.org/2778493002
Cr-Commit-Position: refs/heads/master@{#44126}

[modify] https://crrev.com/ba40bf7a42324d3e58a013e41683ee207f392a0b/src/counters.h
[modify] https://crrev.com/ba40bf7a42324d3e58a013e41683ee207f392a0b/src/wasm/wasm-module.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/15247047e5b63f41d96a509ff91d438ef66f14f2

commit 15247047e5b63f41d96a509ff91d438ef66f14f2
Author: kschimpf <kschimpf@chromium.org>
Date: Mon Mar 27 21:03:39 2017

Separate module decoding counter into asm and wasm counters.

Currently, V8 uses the same counter to collect decoding time for both asm.js and
WASM. This separates that counter into two separate counters, and then uses the appropriate counter when instantiating a module.

BUG= chromium:704922 
R=bbudge@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2780563002
Cr-Commit-Position: refs/heads/master@{#44163}

[modify] https://crrev.com/15247047e5b63f41d96a509ff91d438ef66f14f2/src/counters.h
[modify] https://crrev.com/15247047e5b63f41d96a509ff91d438ef66f14f2/src/wasm/module-decoder.cc
[modify] https://crrev.com/15247047e5b63f41d96a509ff91d438ef66f14f2/src/wasm/wasm-module.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/35701006960e4a6419f2dcb62964cfbb311bcd5a

commit 35701006960e4a6419f2dcb62964cfbb311bcd5a
Author: kschimpf <kschimpf@chromium.org>
Date: Mon Mar 27 21:09:37 2017

Split counters for functions per module for asm and wasm.

Currently, V8 uses the same counter to count both wasm and and asm js. This
splits the counters into two separate counters, and then uses the appropriate
counter when instantiating the module.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2777073003
Cr-Commit-Position: refs/heads/master@{#44164}

[modify] https://crrev.com/35701006960e4a6419f2dcb62964cfbb311bcd5a/src/counters.h
[modify] https://crrev.com/35701006960e4a6419f2dcb62964cfbb311bcd5a/src/wasm/wasm-module.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/7d4cb943036f18bb8a54c239ffe1d5a8a434b584

commit 7d4cb943036f18bb8a54c239ffe1d5a8a434b584
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Mar 28 14:27:42 2017

Separate function decoding counter into asm and wasm counters.

Currently, V8 uses the same counter to collect decoding time for both asm.js and
WASM. This separates the function decoding counter into two separate counters,
and then uses the appropriate counter when decoding a module.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2772363002
Cr-Commit-Position: refs/heads/master@{#44197}

[modify] https://crrev.com/7d4cb943036f18bb8a54c239ffe1d5a8a434b584/src/counters.h
[modify] https://crrev.com/7d4cb943036f18bb8a54c239ffe1d5a8a434b584/src/wasm/module-decoder.cc
[modify] https://crrev.com/7d4cb943036f18bb8a54c239ffe1d5a8a434b584/src/wasm/wasm-module.h
[modify] https://crrev.com/7d4cb943036f18bb8a54c239ffe1d5a8a434b584/test/unittests/wasm/module-decoder-unittest.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/1d4821280b2e09292e80d873dfff816939809c69

commit 1d4821280b2e09292e80d873dfff816939809c69
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Mar 28 18:14:12 2017

Separate module min memory pages counter for asm.js/WASM.

Currently, V8 uses the same size counter to measure the minimum number of memory pages allocated by a module for both asm.js and WASM. This CL separates the counter into two separate counters, and then uses the appropriate counter when measuring.

BUG= chromium:704922 
R=mtrofin@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2781453004
Cr-Commit-Position: refs/heads/master@{#44204}

[modify] https://crrev.com/1d4821280b2e09292e80d873dfff816939809c69/src/counters.h
[modify] https://crrev.com/1d4821280b2e09292e80d873dfff816939809c69/src/wasm/wasm-module.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/d7d201d4128f573917c5cef67c8ef3fce63e73bf

commit d7d201d4128f573917c5cef67c8ef3fce63e73bf
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Mar 28 18:18:37 2017

Separate function byte size counter for asm.js/wasm.

Currently, V8 uses the same size counter to measure function byte sizes for both
asm.js and WASM. This CL separates the counter into two separate counters, and
then uses the appropriate counter when decoding.

BUG= chromium:704922 
R=bbudge@google.com,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2780783003
Cr-Commit-Position: refs/heads/master@{#44205}

[modify] https://crrev.com/d7d201d4128f573917c5cef67c8ef3fce63e73bf/src/counters.h
[modify] https://crrev.com/d7d201d4128f573917c5cef67c8ef3fce63e73bf/src/wasm/module-decoder.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/759db9fcc88b3c99f4365f2db7d4441f284e76c1

commit 759db9fcc88b3c99f4365f2db7d4441f284e76c1
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Mar 28 20:00:10 2017

Separate decoding module peak memory bytes for asm/wasm.

Currently, V8 uses the same counter to measue module decoding peak memory bytes
for both asm.js and WASM. This CL separates the counter into two separate
counters, and then uses the appropriate counter when decoding a module.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2778973003
Cr-Commit-Position: refs/heads/master@{#44207}

[modify] https://crrev.com/759db9fcc88b3c99f4365f2db7d4441f284e76c1/src/counters.h
[modify] https://crrev.com/759db9fcc88b3c99f4365f2db7d4441f284e76c1/src/wasm/module-decoder.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/90c12512d9f79ab9603db86d228df200e581880b

commit 90c12512d9f79ab9603db86d228df200e581880b
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Mar 28 21:22:16 2017

Separate module max memory pages counter for asm.js/WASM.

Currently, V* uses the same size counter to measure the maximum number
of memory pages allocated by a module for both asm.js and WASM. This
CL separates the counter into two separate counters, and then uses the
appropriate counter when measuring.

BUG= chromium:704922 
R=mtrofin@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2783713002
Cr-Commit-Position: refs/heads/master@{#44210}

[modify] https://crrev.com/90c12512d9f79ab9603db86d228df200e581880b/src/counters.h
[modify] https://crrev.com/90c12512d9f79ab9603db86d228df200e581880b/src/wasm/wasm-module.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/4e3f4b2d121dc9c77a880b16f82a1af277a23a27

commit 4e3f4b2d121dc9c77a880b16f82a1af277a23a27
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Mar 28 22:09:13 2017

Separate module byte size counter for asm.js/wasm.

Currently, V8 uses the same size counter to measure module sizes for both asm.js
and WASM. This CL separates the counter into two separate counters, and then
uses the appropriate counter when decoding.

BUG= chromium:704922 
R=mtrofin@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2777203005
Cr-Commit-Position: refs/heads/master@{#44211}

[modify] https://crrev.com/4e3f4b2d121dc9c77a880b16f82a1af277a23a27/src/counters.h
[modify] https://crrev.com/4e3f4b2d121dc9c77a880b16f82a1af277a23a27/src/wasm/module-decoder.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/85d731e930c16b048bef14af941d1010c04b0759

commit 85d731e930c16b048bef14af941d1010c04b0759
Author: kschimpf <kschimpf@chromium.org>
Date: Wed Mar 29 22:38:38 2017

Change Chrome name for histograms to show asm/wasm targets.

Do final change to Chrome flags so that UMA will start collecting
separate statistics, using a "histogram_suffixes" format.

Corresponding changes to chromium are in:

CL https://codereview.chromium.org/2781163002

BUG= chromium:704922 
R=bradnelson@chromium.org,bbudge@chromium.org

Review-Url: https://codereview.chromium.org/2781073003
Cr-Commit-Position: refs/heads/master@{#44255}

[modify] https://crrev.com/85d731e930c16b048bef14af941d1010c04b0759/src/counters.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/76f352d199b02329412d95dca14fb8985968c62a

commit 76f352d199b02329412d95dca14fb8985968c62a
Author: kschimpf <kschimpf@chromium.org>
Date: Thu Mar 30 17:01:32 2017

Modify V8 histograms by adding asm/wasm suffices.

Do final change to chrome histogram flags so that V8 UMA will start collecting separate statistics for asm.js and WASM modules.

This is being done because asm.js and WASM modules have different
semantics and size expectations, making it very hard to tell what are
asm.js issues and what are WASM module issues. To fix this, adding
suffixes "asm" and "wasm" to current histograms.

Code for V8 has already been modified to collect separately, except
for histogram table names. This fianl fix for histogram table names
can be found in:

CL https://codereview.chromium.org/2781073003

BUG= chromium:704922 
R=isherman@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2781163002
Cr-Commit-Position: refs/heads/master@{#460801}

[modify] https://crrev.com/76f352d199b02329412d95dca14fb8985968c62a/tools/metrics/histograms/histograms.xml

We should also track how often shared-memory allocations fail (especially in 32-bit versions of chrome), to see get better insight into when this is happening.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/114d6b4b87691fcbb3613c5de377d3d6805bf3e2

commit 114d6b4b87691fcbb3613c5de377d3d6805bf3e2
Author: kschimpf <kschimpf@chromium.org>
Date: Thu Mar 30 21:19:29 2017

Remove fixed TODOs.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2786193002
Cr-Commit-Position: refs/heads/master@{#44281}

[modify] https://crrev.com/114d6b4b87691fcbb3613c5de377d3d6805bf3e2/src/counters.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/182a216ffc40fec6d772cb33d2b0b018def2c2eb

commit 182a216ffc40fec6d772cb33d2b0b018def2c2eb
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 31 15:20:30 2017

Increase the range of WasmCompileModuleMicroSeconds histogram.

Looking at UMA results, we are getting a lot of compilations (over 5%)
that are being lumped into the 1 second (plus) maximum entry. To get
more visibility into this, this CL lifts the maxiumum to 10 seconds.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2785313002
Cr-Commit-Position: refs/heads/master@{#44312}

[modify] https://crrev.com/182a216ffc40fec6d772cb33d2b0b018def2c2eb/src/counters.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/9fc6398f72a77bb32b219b10c68ae6f67c501f09

commit 9fc6398f72a77bb32b219b10c68ae6f67c501f09
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 31 15:22:30 2017

Increase the range of WasmInstanteModuleMicroSeconds histograms.

Looking at UMA results, we are geting a number of instantiations (4%)
that are being lumped into the 1 second (plus) maximum entry. To get
more visibility into the values in this bucket, this CL lift the
maximun to 10 seconds.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2780353004
Cr-Commit-Position: refs/heads/master@{#44313}

[modify] https://crrev.com/9fc6398f72a77bb32b219b10c68ae6f67c501f09/src/counters.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/8ed72f91a01a72b9adb8125b53f19cbaa50c694c

commit 8ed72f91a01a72b9adb8125b53f19cbaa50c694c
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 31 15:24:31 2017

Increase the range of WasmFunctionsPerModule histogram.

Looking at UMA results, we are getting a fair number of modules with
more than 10,000 functions (5.2%) that are being lumped into the
maximal entry. To get more visibility into what values are being
lumped, this CL lifts the maximum to 100,000.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org

Review-Url: https://codereview.chromium.org/2787163002
Cr-Commit-Position: refs/heads/master@{#44314}

[modify] https://crrev.com/8ed72f91a01a72b9adb8125b53f19cbaa50c694c/src/counters.h

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/0c5f5a3acf284d4fffd84fd08efa154cb1a132b5

commit 0c5f5a3acf284d4fffd84fd08efa154cb1a132b5
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 31 21:45:21 2017

Track large array buffer allocations.

Adds a counter for large array buffers. Used to give an indication of
how common large array buffers are allocated in V8.

For the moment, we assume a 1Mb cutoff for the notion of large array
buffers.  We also use log2(length) to cleanly bucket sizes into a
histogram.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2792623002
Cr-Commit-Position: refs/heads/master@{#44317}

[modify] https://crrev.com/0c5f5a3acf284d4fffd84fd08efa154cb1a132b5/src/counters.h
[modify] https://crrev.com/0c5f5a3acf284d4fffd84fd08efa154cb1a132b5/src/objects.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/9e28cf1318c9ff274ef7599127f7af4cb51b42b5

commit 9e28cf1318c9ff274ef7599127f7af4cb51b42b5
Author: kschimpf <kschimpf@chromium.org>
Date: Fri Mar 31 22:19:39 2017

Add counter for new shared/array buffers that fail to allocate space.

Records histogram of ArrayBuffer/SharedArrayBuffer new allocations
that failed because it couldn't allocate space for the
buffer. Histogram is based on the buffer size requested.

This counter is intended to give some clue as to how often, and what sizes are being requested. Unfortunately, the how often can't be answered with the current counter. The problem is that V8 doesn't currently support this possibility yet. Hence, for now, introducing a counter that at least counts the number/size of failing requests.

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2786913004
Cr-Commit-Position: refs/heads/master@{#44318}

[modify] https://crrev.com/9e28cf1318c9ff274ef7599127f7af4cb51b42b5/src/counters.h
[modify] https://crrev.com/9e28cf1318c9ff274ef7599127f7af4cb51b42b5/src/objects.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/510abe732e132b8a876374b13d5f632086064a72

commit 510abe732e132b8a876374b13d5f632086064a72
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Apr 04 17:26:08 2017

Collect array buffer allocation sizes for UMA in megabytes.

After discussion with Chrome reviewers for UMA, it was decided that we
would report array buffer allocation sizes in megabytes (not the log).

They also wanted to wait until there is proof that small array buffer
allocations would flood the histogram. Hence, all allocation sizes are
sampled.

There were several ways we could have added the notion of megabyte
samples to V8 code. None of them are a great fit.  This code simply
provides a local function within the code that needs it.

Other possible solutions but rejected were:

a) Use a subclass of histogram to collect data at the megabyte level.
   It has it's own Add() method that converts the size from bytes to
   megabytes, and then call the generic add method AddSample(). This
   solution appears to follow the conventions of subclasses of class
   Histogram.

b) Use Chrome macros - Rejected because it involves changing the
   counter representation of V8.

c) Add a method AddMegabyteSample() to base class Histogram. Rejected
   because it may get confusing if a lot of different measures are
   added the the base class of histograms.

d) Make method AddSample() virtual and override in the derived
   class. Rejected in that sampling is supposed to be fast, and adding
   a virtual call may be breaking that contract.

d) Do not add a derived class. Rather just do the conversions at the
   call sites. Rejected because this duplicates code, and also makes
   it hard to change assumptions on how to calculate.

For Chromes UMA changes see:

CL: https://codereview.chromium.org/2795463002

BUG= chromium:704922 
R=bbudge@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2795763002
Cr-Commit-Position: refs/heads/master@{#44388}

[modify] https://crrev.com/510abe732e132b8a876374b13d5f632086064a72/src/counters.h
[modify] https://crrev.com/510abe732e132b8a876374b13d5f632086064a72/src/objects.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c69cbb716c31aa6fc635f52d314781d35222b73f

commit c69cbb716c31aa6fc635f52d314781d35222b73f
Author: kschimpf <kschimpf@chromium.org>
Date: Tue Apr 04 18:35:02 2017

Add histograms to track issues with JavaScript array buffers.

There has been concerns about that WASM could be using very large
Javascript array buffers (including shared array buffers). Currently,
there is no visibility to check this presumption.

This CL is to (at least temporarily) add to UMA histograms to get a
better understanding of this potential issue. It creates two
histograms. The first shows the frequency of allocating array buffers
of at least size 1Mb. The other shows the relative sizes of array
buffers when the memory request is unable to be met.

See the following for the corresponding V8 changes:

Large buffers: https://codereview.chromium.org/2792623002
New failures: https://codereview.chromium.org/2786913004
Fix to megabtye sizes: https://codereview.chromium.org/2795763002

BUG= chromium:704922 
R=bbudge@chromium.org,brannelson@chromium.or,isherman@chromium.org,mtrofin@chromium.org

Review-Url: https://codereview.chromium.org/2795463002
Cr-Commit-Position: refs/heads/master@{#461780}

[modify] https://crrev.com/c69cbb716c31aa6fc635f52d314781d35222b73f/tools/metrics/histograms/histograms.xml

I've been watching UMA stat V8.ArrayBufferBigAllocations for several weeks, and at least 98.93% of the entries are in the first entry of the table (i.e < 1Mb).

I propose that we remove such entries so that the distribution in the rest of the graph is visible.