Firefox Browser Going On A Memory Diet

Mozilla officials admit Firefox continues to rely on a monolithic architecture that can lead to instability and memory leaks.

By Thomas Claburn, InformationWeek
March 25, 2009

Mozilla, faced with more insistent competition for Web browser market share from Apple, Google, and M*crosoft, is asking for help managing Firefox’s appetite for memory.

In a blog post on Monday, Ben Galbraith, co-director of developer tools at Mozilla, explains that browsers are evolving from page rendering applications into application runtime environments. As that change occurs, browsers can provide many of the functions of operating systems. That, incidentally, is why M*crosoft tried so hard to eliminate Netscape not so long ago.

Galbraith credits this shift partly to Google’s “creation of boundary-pushing ‘desktop-quality’ applications” and its evangelization of its Chrome browser as an application runtime. That’s generous praise given that Google’s decision last year to introduce a browser of its own raised questions that still haven’t been satisfactorily answered about the future of the relationship between Google and Mozilla.

One thing that might quiet worries about rising friction between the two organizations would be seeing Firefox back at the head of the browser technology race. If Firefox remains strong, it should continue to be able to collect revenue from Google, not to mention M*crosoft or Yahoo, in exchange for searches sent through the browser’s search box.

Over the past few years, Firefox set the pace of browser innovation. But it has been caught or passed by Chrome 2, Safari 4, and Internet Explorer 8. The competition has been getting faster and has added advanced features like pre-emptive threading and memory protection for tabs.

Firefox continues to rely on a monolithic architecture that can lead to instability and memory leaks, which have bedeviled Firefox’s developers for years. It’s a problem aggravated when Firefox plug-ins aren’t coded well. Particularly in light of Chrome’s responsiveness and low memory footprint, it’s clear that Firefox needs some help, even it remains far more feature-rich than the competition.

Galbraith wants the Mozilla developer community to help solve Firefox’s memory problems, and those of other applications, by creating an open source tool to make application memory garbage collection (GC) — the process by which programs clear unneeded objects from memory — easier to understand and manage.

“We plan on the initial implementation of this tool to be simple,” he explains. “For memory usage, we want to introduce the ability to visualize the current set of non-collectible JavaScript objects at any point in time (i.e., the heap) and give you the ability to understand why those objects aren’t collectible (i.e., trace any object to a GC root). For the cycle collector, we want to give you a way to understand when a collection starts and when it finishes and thus understand how long it took.”

Firefox is still quite popular and its usage continues to grow. It captured a worldwide market share of 21.77% in February, according to Net Applications. It remains the most customizable browser, with a wide selection of plug-ins. Firefox developers are also working on technology like the Ubiquity command line interface that no other browser can yet match.

But without fundamentals like speed and efficient memory usage, Firefox could lose ground.

Mozilla has been slow to deliver Firefox 3.1, which was supposed to be available in December and is now scheduled for the second quarter of 2009, owning to technical issues with its TraceMonkey JavaScript engine.

Firefox needs the speed that comes with TraceMonkey. And it needs the stability and efficiency that come with well-managed memory usage. It cannot afford to innovate at the edges while remaining bloated at the core.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.