IPC::Message has a lot of subclasses: https://dxr.mozilla.org/mozilla-central/search?q=derived%3AIPC%3A%3AMessage&redirect=false&case=false Most of the subclasses are auto-generated from ipdl: http://mxr.mozilla.org/mozilla-central/source/ipc/ipdl/ipdl/lower.py#1900 And all of them require a vtable: froydnj@thor:/opt/build/froydnj/build-android$ readelf -sW toolkit/library/libxul.so |c++filt|egrep -c 'vtable.*::Msg_' 1428 froydnj@thor:/opt/build/froydnj/build-android$ readelf -sW toolkit/library/libxul.so |c++filt|egrep -c 'vtable.*::Reply_' 364 So roughly ~1800 Message subclasses, with 16 bytes per vtable, which comes out to ~28KB of vtables (on 32-bit, so double that on 64-bit). Here's the thing, though: all those vtables are solely due to Message having a virtual destructor, as proper object-oriented design would have it. Except that *none* of the subclasses have any interesting members to destruct; the only subclass that even has additional members is SyncMessage: https://dxr.mozilla.org/mozilla-central/source/ipc/chromium/src/chrome/common/ipc_sync_message.h#23 Both of the additional members are POD and therefore require no special treatment from the subclass's destructor. So these vtables are pure bloat, size-wise, and add extra instructions at runtime, etc. etc. We also pay some non-zero cost for relocations of the function pointers in the vtables, both in binary size and startup time. I think we should fix this. We could simply make Message's destructor non-virtual. But that means that if somebody did add a Message subclass with non-POD classes that required destruction, we would be hosed. The only solution I have to this is a static analysis attribute on Message that enforces POD-ness on all subclasses' members as well as no user-defined destructors for the subclasses...maybe with a few other tricks as well.

Sigh, bugzilla.