This is why memory fragmentation is bad

https://bugzilla.mozilla.org/show_bug.cgi?id=666058#c31

by saulrh • 15 years ago

144 94 15 years ago

bugzilla.mozilla.org

saulrh7• 15 years ago

Summary: Firefox has a bunch of long-living system javascript objects; these get fragmented in the javascript engine's heap and end up keeping alive a bunch of mostly-empty chunks of memory. Tests show that removing this fragmentation reduces Firefox's overall memory use by up to 35%.

iam2• 15 years ago

What's actually surprising is that it took them this many years to get it fixed. Memory fragmentation is just as bad as memory leaks. To the user, the RAM being used just keeps going up and up until they run out of memory and have to restart FF.

ootachi5• 15 years ago

See my comment below; Mozilla has been well aware of memory fragmentation for years and has been constantly working to decrease it.

iam2• 15 years ago

I remember that blog post like it was yesterday. I guess the Mozilla source code is such a gargantuan beast at this point that it really does take years to get significant improvements into it?

Could explain their recent flurries of rewriting the javascript jits.

nnethercote5• 15 years ago

A colleague of mine said "eternal vigilance is the price of low memory usage". Firefox's memory behaviour has varied over the years. FF3.6 was fairly good. FF4 wasn't good. FF5 is a bit better. FF7 is looking like it will be much better. You can get Nightly builds of FF7 now (nightly.mozilla.org), and you'll be able to get Aurora builds of it in a couple of days.

bzbarsky7• 15 years ago

This particular fragmentation issue was introduced sometime around November 2010. So it took about 5 months to find and a bit of time to fix.

> Memory fragmentation is just as bad as memory leaks.

Indeed.

anygregor2• 15 years ago

I don't think so. This bug has been around since the introduction of our current chunk allocation model. So many many years.

Impossible• 15 years ago

Glad to see they are finally doing something to address memory fragmentation besides suggesting that users "occasionally restart Firefox". Seems like this has been a major problem in Firefox forever.

ootachi5• 15 years ago

Mozilla has been well aware of this problem for years. See this blog post from 2008, 3 years ago, detailing the changes that went into optimizing memory use for Firefox 3, including switching to jemalloc to decrease fragmentation: http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/

spitfire• 15 years ago

The sad state of affairs is that papercuts are the death of us all. We've come to the point where we have "unlimited" resources that we just throw away memory like it's going out of style.

I remember a profiling of a gnome startup. It touched something like insane like 40K files. Another profile I saw removed a few bytes (unneeded, it wasn't some complex optimization) from some commonly used datas-tructure for an 50%+ speed improvement.

Simply we're being cut to death by bloat and pure, sheer lazyness. a web browser has absolutely no excuse for using 500megs of ram. None. Whatsoever.

I expect this comment to fall on deaf ears.

mcpherrinm2• 15 years ago

What if I have 10 tabs open, each with 5 images that are 10mb each? It's not an unreasonable workload.

Yet there's 500mb, right there. Never? Whatsoever? I don't think so.

spicyj• 15 years ago

I seriously doubt you're opening many pages with 10 MB images; even 1 MB is considered pretty large for a web image.

ootachi5• 15 years ago

"Simply we're being cut to death by bloat and pure, sheer lazyness."

All these memory leaks being fixed are "pure, sheer lazyness"?

https://bugzilla.mozilla.org/buglist.cgi?keywords=mlk%2C%20&...

ak217• 15 years ago

That's not what spitfire meant. He meant that the people who put the features responsible for these extra fields/leaks/fragmentation/etc. were not thoroughly performance tested or thought out with performance in mind, out of laziness.

nnethercote5• 15 years ago

The key word here is "workload". A web browser is a programming environment. It would be silly to say "no single native program should use 500MB of RAM", and it's equally silly to say that no website (and by extension, the browser) should use that much.

That's not to say Firefox's memory usage is perfect, far from it. That's why we're making improvements like this one. See https://wiki.mozilla.org/Performance/MemShrink for more.

saulrh7• 15 years ago

It's not just a programming environment, either; a web browser is an interpreter for some of the most poorly-written, highest-level code in existence. Not very conducive to good memory usage even theoretically.

gorbachev• 15 years ago

I agree on your principle, but not with the 500MB comment.

You don't know how people use their browsers.

For example, I have 8 tab groups open right now, each with 5 - 20 tabs. Let's say that's about 75 tabs. That's only 6.67MB each to fill 500MB. I'm regularly over a 1GB. I'm sure a significant part of that is actually memory leaks, but that's beside the point.

michael_dorfman• 15 years ago

Wait, you have 75 tabs open? Doesn't the time it takes to locate the tab you are looking for exceed the time it would take to launch a new tab, and load the desired page?

gnosis• 15 years ago

There's really no reason why browsers couldn't have an option to make tabs which aren't currently active (ie. being viewed) be treated as bookmarks, which take up virtually no memory, since all they are are a URL and a bit of metadata.

This would, of course, slow down browsing when switching from tab to tab, since the entire page would need to be reloaded. But I would gladly give up some speed for memory on my old machine with only 3.7 gigs of RAM.

Before anyone asks why don't I just use bookmarks in the first place, let me say that I prefer the organization that tabs give me for pages I am currently working on. I do move those tabs to bookmarks if I use them long enough. But in the relatively short term I prefer tabs.

Another option that would be a compromise between the solution proposed above and keeping all tabs in memory would be to keep only the N most recently accessed tabs in memory, and treat the rest as bookmarks. That would make switching between those N tabs relatively responsive, but still use a lot less memory than having every page for every tab reside in memory. Especially for people like me, who regularly have over 100 tabs open.

Of course, the value of N should be user-configurable. With a N=1, the second proposed solution would be equivalent to the first.

wheels2• 15 years ago

Your comment is wrong on so many levels:

• It's not even on topic. This post is not about general memory usage; it's about fragmentation in the javascript VM – i.e. that a system object existing in a general memory page precludes that page from being garbage collected / deallocated even though the lifetime of system objects is very different. This is not a trivial matter for which the only explanation is laziness.

• It's spoken like someone who's never seriously worked on a large open source project. Memory profiling and leak tracking is done widely and often (using valgrind, mostly).

• You speak as if you know how much memory a web browser should use. How do you know? Have you worked on modern web browsers? Or are you just, as I assume, by fiat deciding that 500 MB is too much?

• There's very often a speed / memory usage tradeoff. At present, especially for web browsers, users tend to prefer speed. (i.e. how many rendered pages do you cache per tab so that clicking the back button is next to instant?)

• The right time to profile and optimize is usually later in the development process. We all know the famous quote. Optimizing early tends to lead to ugly code that, amusingly, is harder to optimize later.

z92• 15 years ago

I remember sometime back probably around 2004. There was a lot of noise regarding memory leak in FF. And the expert sounding ones started to claim that there was no memory leak and the very large memory usage in FF was because of browser history and cache storage. Then one year later they all accepted that FF was actually leaking memory.

Since then I stopped accepting expert opinion blindly.

jbert4• 15 years ago

> • There's very often a speed / memory usage tradeoff. At present, especially for web browsers, users tend to prefer speed. (i.e. how many rendered pages do you cache per tab so that clicking the back button is next to instant?)

This is a good point, and the amount of memory used for such a cache is ideally "all of it, but no more".

Which is the same argument for buffer cache.

So I wonder if it's possible to use the buffer cache in this way?

Perhaps write the rendered image to a tmpfile. Then don't sync the write and also something like fadvise(FADV_DONTNEED). The app can then free the memory. (Clearly you could play a similar game with mmap()).

The idea would be to have the memory sitting in the system buffers. But the app can inform the system that these pages are discardable under memory pressure, rather than needing to be written to disk.

srean• 15 years ago

While not right square on topic I dont think the parent post was so off target compared to digressions and explorations that are common on discussions here that it warranted an admonishment. I have not "worked on modern browsers" and that seems to disqualify me from expressing an opinion on what I consider using too much as an user of a piece of software.

But this much I can say, that even a few years back I could comfortably use a Linux desktop on 64MB RAM. Now even a Debian box with X would run rather choppily on a system that has 256MB and it is not very clear to me in what exact way is my compute experience better now than the one that I had on the 64MB system. Even those that are considered a lean browser, take upto 200MB of that 256 and still does not work smoothly.(FF 3.5 still does fine on this system BTW). Had my old system been augmented with some 3Gigs of RAM it is possible that its performance would be worse than a modern system of equivalent RAM, but now that it is common for a system to occupy more resources to accomplish the same level of activity is at times an irritant.

The usual counterargument is that RAM is cheap and one should just go and buy some or suffer otherwise. I think it is this assumption that is made or a requirement that is imposed by the newer versions of software that GP was complaining about.

mike-cardwell• 15 years ago

"There's very often a speed / memory usage tradeoff."

And yet Firefox seems to use about 4 or 5 times more memory than Chrome on my system whilst being noticably slower as well...

If Chrome had all the addons that Firefox had, Firefox would be a dead browser.

I still use Firefox as my primary browser. For now.

demallien• 15 years ago

It's not laziness, it's all about avoiding premature optimisations. Personally I write the bulk of my code on embedded systems where we are severly constrained both in sheer CPU performance, but also in the amount of memory available. Nevertheless, I still start off writing code in what you might call a "lazy" style, but which I tend to think of as "the simplest, clearest way to write code to do the job". I assume I'll have the memory and the performance that I need. Having written the code, if that assumption turns out to be false, only then do I go back and try to improve performance characteristics - adding caching, optimising algorithms to avoid doing unnecessary calculations, and so on. The code is inevitably longer, and less flexible, after this work which means that I have probably added in bugs during the process. And that is why I don't start off doing things that way, I'm trying to keep the LOC count (and hence the bug count) down as much as possible. Memory and performance optimisations are done only when the is a demonstrated need for them, and I feel that this is the correct way to approach optimisation.

JoeAltmaier2• 15 years ago

Yeah; sounds like a good process. But all too often the "try to improve performance characteristics" part is entirely skipped. It doesn't take much to run A/B tests and wonder why you are 5X over other similar apps. It was clearly never done, at least not by anybody in a position to help mitigate the issue.

I use a similar version of your processes. adding: when code complete examine the footprint and speed, and diligently explain to myself where the time/memory went. If it was wasted, do something about it immediatley.

techdmn• 15 years ago

Obligatory Abrash quote: "In the long run, programs will be bigger and slower yet, but computers will be so fast and will have so much memory that no one will care." [1] I don't agree 100%, but he has a point. I'll say that resources are cheap enough they aren't always worth optimizing. On the other hand, it's easy to get caught on the wrong side of that. Always painful to discover that someone else's "plenty to spare" is your "just a bit short".

[1] http://www.phatcode.net/res/224/files/html/ch39/39-01.html

clobber2• 15 years ago

He mentioned wanting to get that patch into FF7. Why not FF6?

saulrh7• 15 years ago

https://wiki.mozilla.org/Releases#Firefox_6

FF6 has already been frozen and released to the Aurora channel; it goes to Beta tomorrow. FF7's code gets frozen and released to Aurora tomorrow.

linker3000• 15 years ago

By the time we get to FF412 in a month or so I expect it will be awesome and actually ordering me free RAM from Crucial

fomojola2• 15 years ago

Remarkable: "No we don't free chunks right away (except with the new SHRINK GC call). They survive 3 GCs because of allocation heavy workloads. Freeing and allocating right away hurts benchmark performance (bug 541140)."

So they're basically saying one of the reasons a copy of Firefox with no open tabs is currently consuming 1GB of my computer's memory is because they didn't want to suck on benchmarks. Is there a flag I can set to tell the damn browser "I AM A REAL USER AND NOT A BENCHMARK, PLEASE DON'T SIT ON 1GB OF MEMORY, FREE IT IMMEDIATELY"?

nnethercote5• 15 years ago

In FF6 (available right now on the Aurora channel and in the next few days on the Beta channel) and later versions you can go to about:memory and click on the "minimize memory usage" button at the bottom. Maybe do it a couple of times for luck.

We're working on improving things. See https://bugzilla.mozilla.org/show_bug.cgi?id=656120 for another big improvement that will go into FF7.

fomojola2• 15 years ago

Neat: will actually give me a reason to upgrade from 3.6.

jfager• 15 years ago

That's a terribly depressing thread towards the end.

jrockway• 15 years ago

I have 6G of core and 4G of swap. If using more memory makes browsing faster, I'm all for it. Memory is cheap. CPU time is expensive.

For reference: 24G of DDR3 costs about $220 these days.

rwg• 15 years ago

All of the physical RAM in the world doesn't mean a damned thing if you're a Win32 process limited to 2 GiB of user address space. Heap fragmentation is a very real problem there.

mixmastamyk3• 15 years ago

Doesnt matter how much youve got if usage continues to grow unchecked.

perlgeek• 15 years ago

On machines where I have at least 4G of ram, I configure them to not use any swap space at all.

If a process needs (or pretends to need) that much memory, the swapping will just kill the performance, and the machine gets unresponsive. I rather have the OOM killer do its job, have a few processes dying and be able to continue using the machine.

JoeAltmaier2• 15 years ago

...and programmer time costs much more. So yes, normally that's a great attitude.

But still, the app has to run on real machines today. So its worth a "sweeping up" pass before release, to fix gross oversight and bugs that leak/use CPU egregiously.

Confusion• 15 years ago

I think you're jumping the gun. He may be talking about benchmarks that represent the user experience. In which case he's guilty at most for using 'benchmark performance' instead of 'user experience'.

rat• 15 years ago

My guess is that it isn't just because of benchmarks running a gc takes time, running it all at once can be faster then running it multiple times. Getting the right balance can be hard.

anygregor2• 15 years ago

Well that's definitely not only for benchmarks. Whenever you have animations that use JS you will benefit from this approach.

wakemup• 15 years ago

'No we don't free chunks right away (except with the new SHRINK GC call). They survive 3 GCs because of allocation heavy workloads. Freeing and allocating right away hurts benchmark performance'

This is the real problem then - benchmark score vs real-world useabilty.

KobyB• 15 years ago

We measure fragmentation level of disks is a unique way, that allows a central fragmentation control instead of periodical defrag. The idea can be converted to memory fragmentation - if anybody wants to join us for developing a similar tool for cases described here.. Koby http://www.disklace.com

This is why memory fragmentation is bad

Related Stories