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

commit bd599af5d33647f0b498311eab05be79fac98e63
Author: erikchen <erikchen@chromium.org>
Date: Mon May 22 21:15:07 2017

Enable sharding of AllocationRegister on desktop.

Previously, when native heap profiling was enabled, all allocations in a process
were gated by a global lock. This proves to be a significant performance hit on
macOS. Profiling shows that 50-75% of all wall time is spent waiting on this
lock.

This CL introduces a new class ShardedAllocationRegister to handle sharding for
desktop platforms. This stores allocation/backtrace information across 64
different AllocationRegister instances. In addition, the sizes of the fixed size
hash maps were changed. The number of allocation buckets was reduced by a factor
of 8, and the number of backtrace buckets reduced by a factor of 16.

The new class ShardedAllocationRegister is thread-safe, and its consumers no
longer need to acquire a lock when using the container. Each consumer still
needs to know whether heap profiling is enabled. This CL uses a subtle::Atomic32
along with Acquire_Load and Release_Store to determine this state. Using a bool
to record this state and a base::Lock to synchronize reading/writing from the
bool has performance almost as bad as the global lock.

BUG=724651

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

[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/BUILD.gn
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/trace_event/heap_profiler_allocation_register.cc
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/trace_event/heap_profiler_allocation_register.h
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/trace_event/malloc_dump_provider.cc
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/trace_event/malloc_dump_provider.h
[add] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/trace_event/sharded_allocation_register.cc
[add] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/base/trace_event/sharded_allocation_register.h
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/third_party/WebKit/Source/platform/PartitionAllocMemoryDumpProvider.cpp
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/third_party/WebKit/Source/platform/PartitionAllocMemoryDumpProvider.h
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/third_party/WebKit/Source/platform/heap/BlinkGCMemoryDumpProvider.cpp
[modify] https://crrev.com/bd599af5d33647f0b498311eab05be79fac98e63/third_party/WebKit/Source/platform/heap/BlinkGCMemoryDumpProvider.h

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

commit 7de5d92d63eab0410c6e679510ca65941d59587b
Author: etienneb <etienneb@chromium.org>
Date: Wed May 24 17:49:09 2017

Cleanup malloc dump provider after previous refactoring

This CL is a code cleanup after this refactoring:
  https://codereview.chromium.org/2890363003
  https://chromium.googlesource.com/chromium/src/+/bd599af5d33647f0b498311eab05be79fac98e63

CC=erikchen@chromium.org
R=primiano@chromium.org

BUG=724651

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

[modify] https://crrev.com/7de5d92d63eab0410c6e679510ca65941d59587b/base/trace_event/malloc_dump_provider.cc