[tracing]Fix resident size of malloc for mac and ios.

The default system allocator works with 4 allocation regions:
tiny, small, large and huge.
The tiny and small region allocates large vm regions (1-8Mb) and for
each allocation the first continuous chunk that fits the allocation
size is returned. "max_size_in_use" gives the sum of sizes of the
regions without the last chunk that is untouched. So, any region in
this range should either be in use or was in use in the past and freed.
This would mean that this memory is resident (% the memory that client
allocated and not touched).
The large and huge regions maintain the hash table of exact allocation
sizes. So, "max_size_in_use" is the sum of allocated objects size,
which should be resident.

For a 32 bit sytsem, each allocation below 496 bytes(tiny) is rounded
to 16 bytes and each allocation below 47Mb(small) is rounded to 512
bytes. Allocations larger than that are rounded to system page size.
This would cause the "max_size_in_use" to be more than the actual
resident size. But this is the closest approximation to resident size
and on experiments showed that the value at most 4% more than the
actual resident size.

The malloc dumps used to show resident size and allocated objects size.
It is hard to understand why is there a difference. This CL adds an
extra dump to specify what is that memory used for.

This CL also rearranges the #if conditions so that in future tcmalloc
is used in mac, it still shows correct values.

BUG=542584

Review URL: https://codereview.chromium.org/1531463004

Cr-Commit-Position: refs/heads/master@{#366366}


CrOS-Libchrome-Original-Commit: 86f78c1c70715d6f43ab59fa6cc51be4c1dc7774
1 file changed
tree: ade1e54300cab85dbd7772243ed0d2fd537e3dd2
  1. base/
  2. build/
  3. components/
  4. dbus/
  5. device/
  6. ipc/
  7. mojo/
  8. testing/
  9. third_party/
  10. ui/