[tracing] Reduce number of buckets in AllocationRegister.

[tracing] Reduce number of buckets in AllocationRegister.

Recent changes caused AllocationRegister::Cell to grow 4x, and
with 0x40000 buckets it was allocating ~1 GiB on 64-bit systems. That
caused flakiness of AllocationRegister unittests on 64-bit iOS bots.
Also 32-bit Android sometimes refuses to mmap ~512 MiB when
--enable-heap-profiling flag is used.

BUG=608354
Committed: https://crrev.com/260bd00f1c3636b8596172a9c16868f078edad78
Cr-Commit-Position: refs/heads/master@{#391767}

[Dmitry Skiba, 2016-05-04 18:16:32]

dskiba@google.com changed reviewers:
+ primiano@chromium.org

[Primiano Tucci (use gerrit), 2016-05-04 18:17:26]

lgtm

[Dmitry Skiba, 2016-05-05 04:31:52]

So I realized that number of cells (allocations) is (number of buckets) x 10. So
previously we allowed for 2.6M allocations and now for "only" 1.3M. I did some
testing, and after some CNN.com usage max number of allocations was ~200K in
browser process.

So I think 1.3M gives us enough capacity for all usages.

[Dmitry Skiba, 2016-05-05 04:32:10]

The CQ bit was checked by dskiba@google.com

[commit-bot: I haz the power, 2016-05-05 04:32:27]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1954443002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1954443002/1

[commit-bot: I haz the power, 2016-05-05 05:43:11]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-05-05 05:44:34]

Description was changed from

==========
[tracing] Reduce number of buckets in AllocationRegister.

Recent changes caused AllocationRegister::Cell to grow 4x, and
with 0x40000 buckets it was allocating ~1 GiB on 64-bit systems. That
caused flakiness of AllocationRegister unittests on 64-bit iOS bots.
Also 32-bit Android sometimes refuses to mmap ~512 MiB when
--enable-heap-profiling flag is used.

BUG=608354
==========

to

==========
[tracing] Reduce number of buckets in AllocationRegister.

Recent changes caused AllocationRegister::Cell to grow 4x, and
with 0x40000 buckets it was allocating ~1 GiB on 64-bit systems. That
caused flakiness of AllocationRegister unittests on 64-bit iOS bots.
Also 32-bit Android sometimes refuses to mmap ~512 MiB when
--enable-heap-profiling flag is used.

BUG=608354

Committed: https://crrev.com/260bd00f1c3636b8596172a9c16868f078edad78
Cr-Commit-Position: refs/heads/master@{#391767}
==========

[commit-bot: I haz the power, 2016-05-05 05:44:35]

Patchset 1 (id:??) landed as
https://crrev.com/260bd00f1c3636b8596172a9c16868f078edad78
Cr-Commit-Position: refs/heads/master@{#391767}

[Primiano Tucci (use gerrit), 2016-05-05 08:29:21]

On 2016/05/05 05:44:35, commit-bot: I haz the power wrote:
> Patchset 1 (id:??) landed as
> https://crrev.com/260bd00f1c3636b8596172a9c16868f078edad78
> Cr-Commit-Position: refs/heads/master@{#391767}

Thanks for checking.
I just realized that we should have updated the comment that says
  // A value of ~3M entries is large enough to handle spikes in
  // the number of allocations, and modest enough to require no more than a few
  // dozens of MiB of address space.

It's definitely not "a few dozens" anymore :)
Not worth another CL, maybe let's keep in mind for the next ones.