DMD indicates there's over 100KB of unreported arena allocations related to string bundles in content processes [1]. We should at least update `nsStringBundleService` to report its `mBundleMap` [2]. It's also possible that there are other allocations outside of the cache that we should report as well. It also seems like we should be able to share these bundles b/w processes rather than loading in each one. [1] > Unreported { > 50 blocks in heap block record 8 of 3,055 > 102,400 bytes (102,400 requested / 0 slop) > Individual block sizes: 2,048 x 50 > 0.39% of the heap (16.40% cumulative) > 1.26% of unreported (52.63% cumulative) > Allocated at { > #01: mozilla::ArenaAllocator<2048ul, 4ul>::AllocateChunk(unsigned long) (/var/dev/erahm/mozilla-unified/obj-x86_64-pc-linux-gnu-clang-5-debug/dist/include/mozilla/ArenaAllocator.h:196) > #02: mozilla::ArenaAllocator<2048ul, 4ul>::InternalAllocate(unsigned long) (/var/dev/erahm/mozilla-unified/obj-x86_64-pc-linux-gnu-clang-5-debug/dist/include/mozilla/ArenaAllocator.h:230) > #03: nsPersistentProperties::SetStringProperty(nsTSubstring<char> const&, nsTSubstring<char16_t> const&, nsTSubstring<char16_t>&) (/var/dev/erahm/mozilla-unified/xpcom/ds/nsPersistentProperties.cpp:511) > #04: ~nsTSubstring (/var/dev/erahm/mozilla-unified/obj-x86_64-pc-linux-gnu-clang-5-debug/dist/include/nsTSubstring.h:77) > #05: nsPropertiesParser::ParseValueCharacter(char16_t, char16_t const*, char16_t const*&, nsTSubstring<char16_t>&) (/var/dev/erahm/mozilla-unified/xpcom/ds/nsPersistentProperties.cpp:211) > #06: nsPropertiesParser::ParseBuffer(char16_t const*, unsigned int) (/var/dev/erahm/mozilla-unified/xpcom/ds/nsPersistentProperties.cpp:404) > #07: nsPropertiesParser::SegmentWriter(nsIUnicharInputStream*, void*, char16_t const*, unsigned int, unsigned int, unsigned int*) (/var/dev/erahm/mozilla-unified/xpcom/ds/nsPersistentProperties.cpp:332) > #08: nsConverterInputStream::ReadSegments(nsresult (*)(nsIUnicharInputStream*, void*, char16_t const*, unsigned int, unsigned int, unsigned int*), void*, unsigned int, unsigned int*) (/var/dev/erahm/mozilla-unified/intl/uconv/nsConverterInputStream.cpp:139) > #09: nsPersistentProperties::Load(nsIInputStream*) (/var/dev/erahm/mozilla-unified/xpcom/ds/nsPersistentProperties.cpp:475) > #10: nsStringBundle::LoadProperties() (/var/dev/erahm/mozilla-unified/intl/strres/nsStringBundle.cpp:129) > #11: decltype (((*{parm#1}).*{parm#2})()) mozilla::detail::RunnableMethodArguments<>::applyImpl<nsStringBundle, nsresult (nsStringBundle::*)()>(nsStringBundle*, nsresult (nsStringBundle::*)(), mozilla::Tuple<>&, mozilla::IndexSequence<>) (/var/dev/erahm/mozilla-unified/obj-x86_64-pc-linux-gnu-clang-5-debug/dist/include/nsThreadUtils.h:1164) > #12: nsThread::ProcessNextEvent(bool, bool*) (/var/dev/erahm/mozilla-unified/xpcom/threads/nsThread.cpp:1100) > #13: NS_ProcessNextEvent(nsIThread*, bool) (/var/dev/erahm/mozilla-unified/xpcom/threads/nsThreadUtils.cpp:519) > #14: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/var/dev/erahm/mozilla-unified/ipc/glue/MessagePump.cpp:97) > #15: ~AutoRunState (/var/dev/erahm/mozilla-unified/ipc/chromium/src/base/message_loop.cc:599) > #16: nsBaseAppShell::Run() (/var/dev/erahm/mozilla-unified/widget/nsBaseAppShell.cpp:159) > #17: XRE_RunAppShell() (/var/dev/erahm/mozilla-unified/toolkit/xre/nsEmbedFunctions.cpp:893) > #18: mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) (/var/dev/erahm/mozilla-unified/ipc/glue/MessagePump.cpp:269) > #19: ~AutoRunState (/var/dev/erahm/mozilla-unified/ipc/chromium/src/base/message_loop.cc:599) > #20: nsAutoPtr<mozilla::ipc::ProcessChild>::operator->() const (/var/dev/erahm/mozilla-unified/obj-x86_64-pc-linux-gnu-clang-5-debug/dist/include/nsAutoPtr.h:199) > } > } [2] https://searchfox.org/mozilla-central/rev/a0665934fa05158a5a943d4c8b277465910c029c/intl/strres/nsStringBundleService.h#49

In bug 1463587, I'm adding a helper that makes it fairly easy to initialize a block of shared memory in the parent process, remap it as read-only, and then share it with all content processes. We can probably re-use that to share parsed string bundles among content processes that need access to them. Would also probably have the nice side-effect of requiring them to be packed into a compact address space rather than split across a bunch of padded malloced blocks.

This memory is now reported and bug 1470365 took care of more effective sharing, I think we can close it.