MemShrink’s 6th Birthday

MemShrink, it’s still a thing

Although not as active, we still have a MemShrink group at Mozilla. We’ve transitioned from an all out assault on memory usage to mostly just attempting to keep memory usage sane. I wasn’t around when things started, but when I joined there were at least seven people actively attending our MemShrink triage meetings, now we’re down to two. Some members have moved on, others have transitioned through, but really it comes down to the fact that we did a pretty good job of getting memory under control and with limited resources there were more important tasks to look at.

Fear not, we haven’t abandoned the project. We’re just in a bit of a lull. With big pushes for multiple content processes and the Quantum project I think we’re going to see the need to ramp up MemShrink again. In the meantime rest assured we’re still chugging along, just at a slower pace.

Big Ticket Items – 2014

Three years ago Nicholas Nethercote wrote a blog post celebrating MemShrink’s 3rd birthday and put together a list of important work we saw coming up. Lets see how those projects went.

Better regression detection

AWSY has moved into our testing automation system and we are now have automated regression detection through perfherder. I think we can declare victory here.

Devtools

The devtools team added a memory tab. Dan Callahan and Nick Fitzgerald put together a nice writeup of the new memory tool. There’s more work that can be done, but most of the devtools team’s focus is on performance profiling these days. It sounds like it could become a priority again next year.

GC Arena Fragmentation

Jon Coppeard did some heroic work (64 patches!) and got compacting GC landed. Initial measurements showed an 8% reduction in JS memory usage which is quite impressive. You can read more details in a blog post by Jon about [compacting garbage collection in SpiderMonkey].(https://hacks.mozilla.org/2015/07/compacting-garbage-collection-in-spidermonkey/)

Tarako

We actually shipped the 128MB phone! It never took off in it’s target market and eventually the entire FirefoxOS project was shut down, but I’m still super impressed we achieved such a feat.

Windows OOM crashes

This is an ongoing problem. We still think the push to 64-bit Windows builds will be a huge win. We have a plan to upgrade users from 32-bit to 64-bit if their system can handle it and will make 64-bit the default in Firefox 55.

In the meantime the JS engine is now smarter about requesting memory on Windows and multi-process Firefox has shipped.

We had hopes that upgrading our memory allocator would help as well, but we’ve since abandoned that effort.

Big Ticket Items – 2017

That was a nice trip down memory lane, but now we need to look forward. Let’s take a look at some of what I see as our next big ticket items.

Reduce JS memory usage and increase sharing of data across processes

The JavaScript engine is probably our biggest target coming up for reducing memory usage, particularly with multiple content processes enabled. There’s some impressive work going on to have our core JavaScript modules share a single global. Initial testing has shown some pretty big wins for this.

In general we need think about ways to share more data across processes.

Improved devtools for memory analysis

The devtools team did a great job with their initial iteration of memory profiling, but it would be great to see a more refined UI and tie in information from our cycle collector on the C++ side.

Expanded testing

I’d like to get the ATSY project automated so that we can get consistent numbers on how we fare against other browsers. This has been a boon for JavaScript performance, I can see it being a good motivator for improving memory usage as well. An updated test corpus that uses modern web features would be a big improvement. Making it easier to track the memory impact of WebExtensions would also be great.

Conclusions

We ticked off 4 out of 5 of our big ticket items. 64-bit builds on Windows by default is just around the corner so lets just go ahead and count that as 5 out of 5. I see plenty of future challenges for the MemShrink group particularly once the dust settles from enabling multiple content processes and the various Quantum projects.

Let me know if I missed any big improvements, I’m sure there are plenty!

5 thoughts on “MemShrink’s 6th Birthday”

  1. Afaik, bug 1186409 doesn’t having anything to do with sharing across process, just sharing in the same process. Is there other cross-process sharing work that you’re referring to?

    1. Correct, it’s about reducing JS memory usage overall which gets us closer to being able to turn on more content processes. There are a few pie-in-the-sky cross process JS memory bugs, I’ll see if I can dig them up (bug 876173 is one starting point, although not JS specific).

  2. Eric,

    I’m currently using 56.0b12 (64-bit) on Windows 10 64-bit and I’m sat here with 3 tabs open. This site, http://www.memchess.com/ and https://blog.mozilla.org/nnethercote/2017/05/30/memshrink-status/

    Yet according to task manager I’m using 80% of my laptops 4GB of RAM with firefox taking about 1850 MB of that at the moment. About 40 minutes ago I opened loads of YouTube tabs but then shut them again and just had http://www.memchess.com/ open for a while.

    It’s as if Firefox won’t give back the memory from all those YouTube tabs.

    Where is the best place to raise this concern/issue?

    I love 64-bit and multiple content processes, but for me personally, memory usage has become a massive issue in the last 6 weeks or so. Worse than it’s ever been.

    I have to admit I’m not at all technical, merely a fan of Firefox.

    Cheers,

    AC.

    1. Unfortunately task manager doesn’t give the best defaults for it’s memory usage columns, it’s possible that 1850MB is for virtual memory which is less of an issue on 64-bit. If you can reproduce please file a bug and attach an about:memory report.

Leave a Reply

Your email address will not be published. Required fields are marked *