A lot of the "easy wins" have already been won: we reduced the base memory usage on Windows from 21.5MB in 2018 to 14.8MB in 2019, and now 11.5MB in September 2020. This included situations where memory was used excessively, or not released when it could be, and other low-hanging-fruit. However that’s just base memory, the memory used by a content process before it loads a page. Memory usage of the whole browser has increased over the past year (by about 10% as best I can tell from our tracking).

(TL;DR: use a profiler.)

The main goal is to reduce the overhead from enabling fission. There’s multiple places to look:

I’ve picked the 2nd, or almost-2nd one: Reduce the amount of memory overhead for a process loading a tiny page (or iframe). Firefox can generate a memory report, showing where memory is allocated.

With fission enabled I load http://example.com in one tab (because it’s a small page), and open about:memory in another tab, click "Measure" and Firefox will generate a memory report. We’re using this as the starting point for where to concentrate our optimisation efforts.

For a small process we noted that the memory allocator has more overhead than we’d like, >1.90MiB out of a 20.7MiB process (9.21%) and it may be worth-while looking here as place to reduce overheads. This overhead is the bin-unused item on these memory reports. So this is where I’m starting.

Firefox uses a fork of the jemalloc memory allocator, which has now been heavily modified. jemalloc allocates memory in several size classes, the most popular comment in the mozjemalloc.cpp file contains a table explaining its size classes (Table 1):

Note that these sizes can vary with different settings, this is the default on a 32bit build with 4KB pages. On a 64bit build the 4-byte class is missing and windows is always missing the word-sized class.

The 'bin-unused' item on the memory reports is only relevant for the small size classes in this table. In these size classes an area of memory that jemalloc calls a run (one or more pages) is divided up into allocations of this size class, So a request for 12 bytes is rounded up to 16 and allocated in a run that contain other 16 byte allocations. 'bin-unused' measures all the unallocated slots in these runs.

This is not wasted memory or lost memory. But it’s not "merely unused" either. For example, there may be many unused 16-byte slots, even some close together, but they cannot be used to satisfy a request for 32 bytes. And because they’re less than 4KB, they represent physical memory - they cannot be paged out without paging out the rest of that memory page.

(or sometimes more, but for this article I’ll assume a page) will only store items of that specific size class. This reduces overheads since the size information and if this were a GC other metadata) could be shared between all the items in the same page.

I could go on with what I’ve found, and I will but in future posts. By keeping this post shorter I can publish it today. Generally this may help me write more generally, if each post is less time-consuming. So forgive me for leaving you in suspense, but that’s what’s best to maintain a blog at all.

In the next post I’ll write more about bin-unused and something called slop and describe what I might be able to do / have done to fix them. I’ll also write an introductory post about paging.

Thanks for reading.