Track large array buffer allocations.

src/objects.cc

Index: src/objects.cc
diff --git a/src/objects.cc b/src/objects.cc
index fe386ae12723afe650cdeae7ecefed1753a18ea8..bb9cea43a49d324ec4ed2d43ea2d90f4b9c37756 100644
--- a/src/objects.cc
+++ b/src/objects.cc
@@ -19473,6 +19473,14 @@ bool JSArrayBuffer::SetupAllocatingData(Handle<JSArrayBuffer> array_buffer,
   // Prevent creating array buffers when serializing.
   DCHECK(!isolate->serializer_enabled());
   if (allocated_length != 0) {
+    constexpr size_t kMinBigAllocation = 1 << 20;
+    if (allocated_length >= kMinBigAllocation) {
+      isolate->counters()->array_buffer_big_allocations()->AddSample(
+          static_cast<int>(
+              sizeof(size_t) == 32
+                  ? (32 - base::bits::CountLeadingZeros32(allocated_length))
+                  : (64 - base::bits::CountLeadingZeros64(allocated_length))));

[bbudge, 2017/03/31 20:52:28]

You could also just do:

sizeof(uint64_t) * kBitsPerByte -
base::bits::CountLeadingZeros64(allocated_length) - 1

-1 if you wish to map 1 to 0, 2 to 1 etc. I'm not clear on how histograms work
for ranges.

[Mircea Trofin, 2017/03/31 21:01:38]

The pointer sizes are something that may be fishable out of globals.h and you
can use constants then.

[kschimpf, 2017/03/31 21:11:02]

The recommendation is NOT to use value 0 in UMA histograms since that value is
where all out of range data goes. Chrome documentation recommends starting with
1. That is why I did not subtract 1.

Simplifying as suggested otherwise.

[kschimpf, 2017/03/31 21:11:02]

size_t is the number of bytes. Using uint64_t, as Bill suggests, fixes the
issue.

+    }
     if (initialize) {
       data = isolate->array_buffer_allocator()->Allocate(allocated_length);
     } else {