Take a look at the mobile world, especially the game console world. They rarely if ever use generic memory allocation routines like malloc() or free(). Every structure is packed, not necessarily for space, but to avoid having structures with pointers that go out to “random” bits of memory spread all over the place. Contiguous blocks of memory are used to store all the related data for any part of the application. Fragmentation is a lot rarer when the application need only release a single block of memory instead of dozens of blocks spread all over the heap.

This is also a reason that higher-level languages that don’t force programmers to work with raw memory addresses can, despite what a lot of the bitter old crustie programmers think, actually improve performance and memory consumption. A JVM with a good compacting GC avoids the memory fragmentation issue (too bad Java in general promotoes to allocation of billions of little chunks of data almost as much as it promotes the use of billions of threads), which when combined with a good AOT/JIT Java bytecode->machine code compiler can easily give you the raw performance of C combined with memory and cache behavior that aren’t really feasible to get in languages requiring manual memory management (or even assisted manual memory management, a la C++).

Mozilla certainly isn’t going to be rewritten in a language that has automatic memory management (even if it was, there’s no guarantee the common implementations of that language use good automatic memory management – many VMs still use conservative collectors like the Boehm GC), and completely restructuring every data structure to compact allocations would be almost as hard as switching language. Mozilla should instead identify the biggest offenders, and make use of alternative allocators that compact memory.

For example, each page might get a single large block for storing all information about links (I imagine there are a lot of trees and list between small allocated objects to handling that). Instead of just calling malloc()/new to allocate those objects, the objects instead get allocated with a custom allocator that finds a free entry in that block and returns that address. If the block is outgrown, a second block could be allocated. Sure, if blocks are designed to hold 50 link objects, smaller/simpler pages will have a lot of wasted space (where “a lot” is probably well under 1Kb), but when that page is released from memory, that block of links is freed without leaving a bunch of tiny little holes all over the place. Heck, the block itself will probably just be added to a free list to use for the next page load that requests a block for storing links.

I think the “flame gauntlet” in your case comes most significantly from the rudeness and personal attacks, rather from “questioning the development team” — there are routinely quite productive and polite conversations about performance (targets, techniques, results, etc.) in bugs and mailing lists and IRC. I admit that I find it difficult to convince myself that engaging in discussion with you will be productive, given the constant references to irrelevant details and hostility. I’m persevering in this case in hope that the glimmers of constructive suggestion will manifest themselves in something that feels more helpful and less like self-indulgent venting.

You should feel free to post a more balanced comment elsewhere on your own blog, or via email to the dev.performance group, etc. and just track back to here; I follow such things. Please don’t let the small text box compel you to flame, by any means.

We generally don’t announce when people stop working on the project, though people are welcome to do it for themselves of course. I think it’s pretty widely known by people who follow the development and community that Ben hasn’t been active in Firefox in really any form in quite some time. Maybe you weren’t aware of that, but now you are, so the system sorta, kinda works. (Eventually.) If you don’t want to take my word for it, you could ask him yourself, naturally.

Yes, you read that correctly: “It’s not a bug, it’s a feature”.

Perhaps I’m not the one who needs the “basic reading comprehension” skills?

Or perhaps my “basic comprehension skills” are not so bad considering the post to which I commented has now been edited to clarify it’s direction?

Regarding Ben Goodger’s involvement. The last I heard he was physically working at Google but still doing Firefox work. I haven’t seen an announcement to the contrary and I read Planet Mozilla every day. Perhaps I’m meant to interpret the absence of his posts on the Planet Mozilla feed as an ‘announcement’ but unlike the helpful “Planet Mozilla Addition” posts, there don’t seem to be any “Planet Mozilla Removals” posts.

I think this highlights an few issues. One is alluded to in Mike’s post with his use of quotes around ‘”The Mozilla development team”‘. In short I think there is probably a lot of angst in the community (that’s the people who have the time to be involved, not just jo bloggs who wants a browser that works) because there is no real collective policy or voice heard from this arbitrary group of hard-working people – ‘the Mozilla development team’. Certainly Mitchell Baker’s posts never tend to refer to what ‘the Mozilla development team’ is thinking or doing. AFAIK there is no single source of information that communicates the direction and impressions of the low level core developers. Instead anyone interested in questioning ‘the Mozilla development team’ is forced to run the flame guantlet by commenting on blog posts like this.

Now the last thing I would encourage is a situation where developers are bogged down in committees or discouraged from blogging at all. That’s not my point. There must be a happy medium. Perhaps a section on the devmo wiki regularly updated? Topics could include:

• What state we feel Mozilla’s memory footprint is currently at, and what we are doing in this area

• What direction the core developers are heading in with regard to features vs stability/performance, etc. Key metrics like the current number of talkback crash bugs and where that sits on a long term graph would be very interesting.

It’s great that anyone can reach some of the key developers via blog comments and it’s also a flawed and disjointed means of communication.

I apologise if my comment was overtly flame-like. I was angry when I wrote it which is not a great state to be in when posting comments. On the other hand, anger s an emotion towards Firefox that clearly needs communicating; an emotion that the average punter out there who does not read Planet Mozilla would never likely communicate.

I think there must be a better way.

P.S. It’s a bit tough to write a balanced comment when there’s no preview/edit facility available with most blogware :)

Further, the ENTIRE POST is about WHY it turns out Firefox gobbles RAM. In no way is it a denial. It’s an admission of “guilt” then a statement about how a huge goal is to fix it.

So, again, where do you see a denial?

1. People think extensions are leak-proof. When it’s been shown that extensions out there do leak memory. When you add stuff to the browser, you add the potential for problems. IMHO no question Firebug slows things down a little at times (one would expect it to), but IMHO that’s a worthwhile payoff for the functionality it provides. People need to understand extensions a little better.

2. “Open Source” is associated heavily with Linux, which will run on your wrist watch. People assume it’s all the same in design. Firefox isn’t designed for your wrist watch, it’s currently designed for your computer, and soon your mobile device.

pd: you appear to have some anger issues, but I’m not sure how you think it’s defensive: I tried to be quite clear about what we’re doing to improve Firefox’s memory footprint, because in addition to (the proportionately minor) leaks we’ve fixed, we’re also seeing that we cause some pretty ugly behaviour with fragmentation currently. This isn’t blaming Microsoft or Apple for the allocator or anything; we’re responsible for our application’s memory behaviour, and we’re working to fix it (by changing how we allocate, or using a different allocator that has better tradeoffs for us, for example). Many people have expressed concern about Firefox’s memory use over long browsing sessions, and I thought that they would be interested to see inside some of that work. I’m sorry if it wasn’t outright self-immolation, I guess.