1438287 - Reduce the overhead of the xpti working set in content processes

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Boris Zbarsky [:bzbarsky]]

This is mentioned some in bug 1436250 comment 1 and bug 1436250 comment 6, but our xpt bits use some nontrivial per-process memory.  If about:memory measures all of it, it's about .83MB.  That's about 5% of heap-allocated memory for a just-about:blank content process.

Obviously we can make this better by removing more xpidl interfaces.

But fundamentally, isn't this information identical across all processes?  Can we just have the parent process read it from the file once, stick it in some memory that we them map (readonly) into all child processes, and skip both allocating it in child processes and the work of reading it in?  This is more complicated than removing xpidl bits, and of less value the less xpidl bits we have, so not sure about the tradeoffs here.

Comment 1

[Andrew McCreight (out of office until 8/21) [:mccr8]]

Bug 799658 and bug 685241 have some related discussion. (This ended up being avoided in B2G by the Nuwa zygote process forking stuff.)

Comment 2

[Andrew McCreight (out of office until 8/21) [:mccr8]]

I've started looking a little into what the data actually is, and how we could reduce it. njn took a look at this a few years ago (bug 1249174 for instance) so there's not likely to be anything too egregious. Most of the memory is arena allocated. There's 8-byte aligned arenas, which take up 589,824 bytes, and 1-byte aligned arenas (for strings) which take up 204,800 bytes. By my estimates, we could reduce the string data by about 35k by eliminating duplicates (ie the string "nsISupports" appears a bunch of times).

Comment 4

[Andrew McCreight (out of office until 8/21) [:mccr8]]

This data is now all statically allocated and shared.