+1, I would be supportive even if we end up with a memory dump provider which does not expose any "bytes" count (if there are too many structs and things hard to follow) but reports at least cardinalities of things, so we can keep track if number of messages/handles and such grows without any limit.

rockot@ says the most relevant object to count is message-pipes, and it should be pretty straight forward to hook up a MDP. I can take a stab at this.

Thanks for looking. All Mojo handles are ultimately added to the global
HandleTable[1], so that object should probably be the MDP.

Note that there are a few methods there which modify handles_. It is safe
to assume that we do not leak Dispatcher instances as the HandleTable is
their only persistent reference holder over time.

Dispatcher::type() will tell you what kind of dispatcher it is. You could
just track MESSAGE_PIPE dispatchers, or track all of them, broken down by
type, if you think that's useful and straightforward enough.

[1]
https://cs.chromium.org/chromium/src/mojo/edk/system/handle_table.h?rcl=cf255632485f5f62553bbc8ca434e116c7d60f14&l=20

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

commit ea7ac132bcc7d34cff4b68e9d19ba0225d27270a
Author: erikchen <erikchen@chromium.org>
Date: Sat Jun 03 02:40:57 2017

Add a Mojo MemoryDumpProvider.

The MemoryDumpProvider counts Dispatchers and segments them by type.

BUG=705785

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

[modify] https://crrev.com/ea7ac132bcc7d34cff4b68e9d19ba0225d27270a/mojo/edk/system/core.cc
[modify] https://crrev.com/ea7ac132bcc7d34cff4b68e9d19ba0225d27270a/mojo/edk/system/core.h
[modify] https://crrev.com/ea7ac132bcc7d34cff4b68e9d19ba0225d27270a/mojo/edk/system/handle_table.cc
[modify] https://crrev.com/ea7ac132bcc7d34cff4b68e9d19ba0225d27270a/mojo/edk/system/handle_table.h

Nice!

Does it surface number of endpoints? Previously we saw that some of our EM stories have abnormal number of them, causing excessive std::deque memory usage ( issue 719774 ).

I have two implementation-wise suggestions:

1. Transpose values. Right now the code creates a column per dispatcher type, but it would be more convenient to create a value per type instead (i.e. dump "mojo/<dispatcher type>" values). Two advantages: easier to read, and compatible with slow reports.

2. Once (1) is done, this MDP can be whitelisted in the slow reports (go/slow-memory-reports), providing interesting insights from the field. 

@dskiba: on it.

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

commit bf2cf91d6a8240cf080cceb53bc489cce7826c02
Author: erikchen <erikchen@chromium.org>
Date: Tue Jun 06 23:54:41 2017

Change format of data emitted in MemoryDumpProvider.

This CL changes the data from a column per dispatcher type to a value per
dispatcher type, which is easier to read and allows for integration with slow
reports.

BUG=705785

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

[modify] https://crrev.com/bf2cf91d6a8240cf080cceb53bc489cce7826c02/mojo/edk/system/handle_table.cc

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

commit 337e9da889a1982924a7d730ca3e8d6b0bc073d7
Author: erikchen <erikchen@chromium.org>
Date: Fri Jun 09 17:49:45 2017

Minor fixes to Mojo MemoryDumpProvider.

  * Allow values from Mojo MemoryDumpProviders to be captured by slow reports by whitelisting them for background traces.
  * Add a unit test.
  * Fix destructor to correctly unregister the MemoryDumpProvider.

BUG=705785

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

[modify] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/base/trace_event/memory_infra_background_whitelist.cc
[modify] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/mojo/edk/system/BUILD.gn
[modify] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/mojo/edk/system/core.cc
[modify] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/mojo/edk/system/core.h
[modify] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/mojo/edk/system/handle_table.cc
[modify] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/mojo/edk/system/handle_table.h
[add] https://crrev.com/337e9da889a1982924a7d730ca3e8d6b0bc073d7/mojo/edk/system/handle_table_unittest.cc

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

commit 30661e1351e5de95f097bdf40854337200a56d7c
Author: erikchen <erikchen@chromium.org>
Date: Fri Jun 09 21:56:20 2017

Correctly initialize MemoryDumpArgs in the MojoHandleTable test.

BUG=705785

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

[modify] https://crrev.com/30661e1351e5de95f097bdf40854337200a56d7c/mojo/edk/system/handle_table_unittest.cc