Categories
about:memory AdBlock Plus Firefox Memory consumption MemShrink

MemShrink progress, week 27

Adaptive Memory Behaviour

The biggest news this week was that Justin Lebar landed code to make Firefox’s memory consumption adaptive on Windows.  The code works by wrapping VirtualAlloc() and some similar OS-level allocation functions.  Each time memory is allocated, the amount of available virtual and physical memory is measured by the wrapper.  If either of those amounts are below a threshold, a memory pressure event is triggered, which causes numerous components within Firefox to take steps to reduce their memory consumption.

It might not sound like it, but this is a big deal, and it was a MemShrink:P1 bug.  Firefox runs on a huge variety of machines and devices, and trying to find one-size-fits-all heuristics for discarding regenerable data is a recipe for unhappiness somewhere.  Adaptive behaviour is much better.

The initial settings for this feature are conservative, and some tuning may be needed.

  • The threshold used for virtual memory is 128MB, i.e. if the amount of available virtual memory drops below 128MB a memory pressure event is triggered.  (This number can be changed in about:config via the “memory.low_virtual_memory_threshold_mb” setting.) Hopefully this will reduce the number of OOM crashes that occur on Windows.
  • The threshold used for physical memory is 0, which means that it is currently ignored.  (This number can be changed in about:config via the “memory.low_physical_mem_threshold_mb” setting.) The reason for ignoring it currently is that low physical memory may be caused by a program other than Firefox — we don’t want to start discarding data if Firefox is only using a small fraction of physical memory.  In the future we can probably do better here by triggering memory pressure events if the fraction of physical memory used by Firefox exceeds some threshold;  hopefully this will avoid paging when memory usage is high.
  • Memory pressure events are throttled so they aren’t sent more than once every 10 seconds.  (This number can be changed in about:config via the “memory.low_physical_memory_notification_interval_ms” setting.)  This prevents thrashing in cases where the memory pressure events don’t help reduce memory consumption.

Memory pressure events are also currently unevenly observed — plenty of data could be dropped that currently isn’t — so there is room for improvement there.

Finally, there’s another bug still open to add similar adaptive behaviour on Mac, Linux and Android.  Note also that memory pressure events are also triggered on Android when Firefox goes into the background.

Add-ons

There has been good news for add-ons:  the #1, #6 and #8 most popular add-ons on AMO have all recently seen some MemShrink-related improvements.

Adding memory reporters to add-ons is a really good thing to do, and I plan to write some documentation to encourage other add-on developers to follow suit.  However, if you are an add-on developer and are thinking of doing this, I need to stress one thing:  the reports must have KIND_OTHER so that they end up in the “Other Measurements” list in about:memory.  If they are put in the “explicit” tree, then some memory bytes may be counted twice (once by Firefox, once by the add-on) which will completely screw up about:memory’s results.

Memory Reporters

I landed several improvements to memory reporters.

Bug Counts

Here are the current bug counts.

  • P1: 26 (-2/+1)
  • P2: 139 (-6/+6)
  • P3: 64 (-2/+2)
  • Unprioritized: 0 (-1/+0)

Nice to see the total count drop, even if only by one.

Due to the Christmas break there won’t be a MemShrink meeting nor a MemShrink progress report next week.  I’ll be back in two weeks, enjoy the break!

17 replies on “MemShrink progress, week 27”

One small correction (I told you the wrong thing during today’s meeting) — Memory pressure events from low *virtual* memory are *not* throttled. The reasoning is that if we’re about to run out of vmem, we’re probably about to crash.

This is really a great news..is bug 670967 already landed? and wow thumbs to firefox team and you for making changes to memshrink project especially P1 bugs..which was really needed..wish you a very happy christmas nicholas

if the amount of available virtual memory drops below 128MB a memory pressure event is triggered
I wonder if these criteria are practical. If a swap file is large, OS never hits this criterion, because it is frozen doing swap-in and swap-out. I mean, this decision rather belongs to an OS than to Firefox. Is memory consumption adaptive on Linux?

Only in limited cases for the Android port.

“Finally, there’s another bug still open to add similar adaptive behaviour on Mac, Linux and Android. Note also that memory pressure events are also triggered on Android when Firefox goes into the background.”

I think he is talking about the “other” virtual memory, i.e. virtual address space. Plus, you really want to avoid having parts of Firefox being swapped in and out of persistent storage as it can bring the browser to a grinding halt. Reducing the need for swapping and thus improving responsiveness is one of the major reasons MemShrink was started in the first place.

I wonder if these criteria are practical. If a swap file is large, OS never hits this criterion, because it is frozen doing swap-in and swap-out.

Not necessarily! Not all virtual memory allocated to a process takes up space in physical memory or swap. For example, you could mmap a large file and never touch most of it; in this case, virtual address space is allocated to the file, but little physical memory is allocated.

On MacOS, Firefox regularly uses 4x or more vmem than rss. The situation is not as extreme on Windows, but that’s good because Windows has less address space available. 🙂

This news about adaptive memory handling really does sound so simple and logical and therefore very likely to cause improvements.

That’s what I thought when first reading it. Then … the kind of obvious next question is: why didn’t Firefox get this 7 years ago? I guess that question will end up a rhetorical one but really, boy … I’d have thought this sort of emergency parachute style memory handling logic would at least have arrived with, say, version 3, considering how much public agitation there was about Firefox’s bad memory handling.

Anyway congratulations to those who worked on what should be a great fix. I guess it’s like 3rd party insurance: just a safety net but it’s better to have that than not have it.

This is great news that another P1 bug has landed. I’m guessing this one will make it into FF12 in April 2012?

It looks like it will arrive 5 weeks earlier, with Firefox 11. If you look at the bugzilla link Nick gave, you can see that “target milestone” is set to “mozilla11”.

So, it’s now pointless to compare Firefox memory consumption on machines with different amount of RAM?

The current heuristic seems to be that as long as you do not go below 128MB+ of free virtual memory no memory pressure has fired. You could also compare numbers after forcing a memory pressure event in about:memory. Or compare on comparable systems that have the same available memory.

Anyway, the goal is to improve user experience, and the memory pressure events advance that.

Um, so, which interpretation of the term “virtual memory” are you using here? The windows (wrong) meaning or the proper computer science meaning?

Hi Nicholas,

You may remember that I posted a few weeks ago saying that Firefox 9 beta was great and that I could definitely see more memory and performance improvements over Fire 7 and 8. Well I am pleased to say that after a few days of using Firefox 10 beta 1, I can clearly see more memory improvements again. There is an obvious difference between Firefox 9 and Firefox 10 on the beta channel.

I have no hard evidence as such other than saying that nothing has changed on my laptop in the last few weeks but I am using the same heavy tab load and the memory usage displayed by Windows task manager is lower than it was by about 20 MB and the responsiveness and speed feels sharp.

Whatever you guys are doing with the Memshrink project, keep doing it because the results are paying dividends.

I must state again that I use no add-ons other than a dictionary and TestPilot to send data back to Mozilla.

Comments are closed.