From bug 1639922 comment #4:

49,152 bytes (34,656 requested / 14,496 slop)
Individual block sizes: 12,288 x 4
#01: IPC::Channel::Channel(int, IPC::Channel::Mode, IPC::Channel::Listener*) (/Users/andrewmccreight/mc/ipc/chromium/src/chrome/common/ipc_channel_posix.cc:927)

This looks like ChannelImpl, which has an inline buffer for reads and another one for cmsg data.

There's not much to be done about those (although moving them out of line might reduce the clownshoes lossage suggested by a 12k size and 2x4k buffers, and allow dynamically resizing them). It looks like the findings are mostly ChannelImpl allocations and the std:: containers you already looked at.

Considering we only allow 250 descriptors per message, the current size of 4096 + 32 bytes is kind of excessive. It was chosen somewhat arbitrarily in bug 988251.

We might be able to reduce that 250 number as well. It was increased from 7 to 250 in that same bug.

Each content process seems to have about 11-12 channels each when idle (measured with the ipc-channels tree in about:memory), each channel has two ends (in different processes), and this patch should move ChannelImpl from the 12k bucket to the 8k bucket (assuming the table at the top of memory/build/mozjemalloc.cpp is up-to-date). I've adjusted the overhead tag to account for all of that memory.

We'll never read more than MAX_DESCRIPTORS_PER_MESSAGE file descriptors in a
single message, so size the buffer based on that value.

https://hg.mozilla.org/mozilla-central/rev/ce9d3120a097