Softpedia
 

NEWS CATEGORIES:



NEWS ARCHIVE >>
SOFTPEDIA REVIEWS >>
MEET THE EDITORS >>
Home > News > Webmaster > Internet Life

December 12th, 2011, 18:51 GMT · By

Firefox Source Code Is So Big, It Hit the 32-Bit Virtual Address Space Limit

SHARE:

Adjust text size:


Firefox source code is becoming too fat
Enlarge picture
Mozilla, or rather the Firefox team, is facing a somewhat unusual problem that is holding up development in some cases. Firefox can't reliably be compiled because the linker runs out of virtual address space.

The problem stems from the fact that Firefox is built on 32-bit machines which can only access a limited amount of memory even with larger amounts of physical memory.

"This is not the first time we've run into this problem. A couple years ago we hit the 2 GB virtual address space limit. The build machines were changed to use /3GB and that additional GB of address space bought us some time. This time unfortunately the options aren't as easy as flipping a switch," Mozilla's Kyle Huey wrote.

The problem arises during the optimization phase as the Profile-Guided Optimisation method Mozilla uses takes up a lot of memory. Some have proposed that the team stop doing PGO since the performance benefits are not always clear, but the general view is that this is not really an option.

Rather, Mozilla is thinking about splitting up parts of libxul, where much of the core code is grouped. WebGL and ANGLE, which enables WebGL to run on top of Direct3D, code may be a good candidate for splitting, but there are other components as well. Media libraries may be separated as well.

For now though, some newer components and features have been removed, things like Graphite, SPDY, libreg, mostly new additions in Firefox 11.

In the slightly longer term another proposed solution would be to upgrade to using Microsoft Visual C++ 2010. The linker in MSVC 2010 could be more efficient and use up less memory.

Finally, a sort of last resort solution would be to build 32-bit Firefox binaries on 64-bit machines, which can access 4 GB of address space.

FILED UNDER:
Firefox
Mozilla
32-bit

TELL US WHAT YOU THINK:

13,043 hits · 22 comments · Link to this article · Print article · Send to friend · Subscribe to news

MUST-READ RELATED ARTICLES:


Firefox 8 Is Coming in 3 Days, Here's What You Need to Know

Ubuntu 11.10 Runs in Your Browser via HTML5 in Impressive Demo

Firefox 9 Beta Is Almost Ready, Here's What You Need to Know

Google Chrome Overtakes Firefox to Become the No. 2 Browser in the World

Mozilla Highlights the Steps It Takes to Keep Firefox Add-ons Safe from Malicious Sites

READER COMMENTS:


Comment #1 by: gubatron on 12 Dec 2011, 22:06 UTC reply to this comment

DRY principle


Comment #2 by: Nick Duglass on 12 Dec 2011, 22:26 UTC reply to this comment

This is * .

THEY DO NOT COMPILE FIREFOX IN VISUAL STUDIO 2010. Hahaha.

Comment #2.1 by: mentat on 13 Dec 2011, 09:53 GMT

I was just about to write the same, refreshed and saw your post. Still wondering what they are using? VS 2003?

Comment #2.2 by: Lucian Parfeni on 13 Dec 2011, 11:02 GMT

VS 2005 it seems.

Comment #2.3 by: Boris on 13 Dec 2011, 17:58 GMT

If it were compiled in Visual Studio 2010, it wouldn't run on Win2K or on the original WinXP or on WinXPSP1.

So upgrading the compiler would involve dropping support for those operating systems. Doable, of course.

Comment #2.4 by: jlebar on 13 Dec 2011, 18:11 GMT

We compile with VS 2005 because that's the last version which supports Windows 2000 and Windows XP before SP2.


Comment #3 by: Jimbo on 12 Dec 2011, 22:58 UTC reply to this comment

The problem probably stems from the fact that they're using the linker when they're compiling...

Comment #3.1 by: Boris on 13 Dec 2011, 17:59 GMT

Profile-guided optimization is implemented in MSVC by having the linker actually recompile all the code during the link step.


Comment #4 by: Bleeblubb on 12 Dec 2011, 23:04 UTC reply to this comment

The title is wrong is so many ways…


Comment #5 by: Kevin C. on 13 Dec 2011, 04:05 UTC reply to this comment

pretty sure that 64-bit machines can access more than 4 GB of memory.

Comment #5.1 by: Lucian Parfeni on 13 Dec 2011, 07:58 GMT

It would still be the 32-bit linker running on 64-bit machines, giving it 4 GB of memory address space.


Comment #6 by: anon on 13 Dec 2011, 05:53 UTC reply to this comment

" to build 32-bit Firefox binaries on 64-bit machines", why will this be last resort.

Comment #6.1 by: Lucian Parfeni on 13 Dec 2011, 08:00 GMT

Because it would take time to upgrade Mozilla's infrastructure to 64-bit Windows and the team needs to make sure that the switch doesn't introduce new problems. It may have to do this eventually, but Mozilla needs other solutions for the immediate future.


Comment #7 by: Joe on 13 Dec 2011, 08:39 UTC reply to this comment

Because the binary would only run on 64-bit machines.


Comment #8 by: sharpie on 13 Dec 2011, 09:08 UTC reply to this comment

Title is misleading - missing the word 'compile' - This has nothing to do with end users

Comment #8.1 by: Lucian Parfeni on 13 Dec 2011, 10:20 GMT

It has to do with end users if Mozilla has to drop features planned for Firefox 11 or if Firefox is slower because the developers stop using profile-guided optimization.


Comment #9 by: jcranmer on 13 Dec 2011, 18:34 UTC reply to this comment

libreg is not a new addition to Firefox 11; it was a library last needed to import profiles from Firefox 0.9.

Also, in the interest of fairness, I wish to point out that Chrome has failed to be able to do PGO 32-bit builds on Windows for far longer due to the address space problem--so it's "size" is only now at the same state that the other browsers are at.

In the hopes that this clears up some of the misleading bits in the article.


Comment #10 by: David Hagadol on 14 Dec 2011, 15:16 UTC reply to this comment

It's time already to stop supporting 32-bit and make a full 64-bit version of firefox, and start thinking about 128-bit, too!


Comment #11 by: Blackcrack on 16 Dec 2011, 09:44 UTC reply to this comment

Why not now a new start with the knowing of all what work or not work..
cut off the old code and start again with Firefox Developeing, maby in Assembly, this is not need mutch space and work the new assemblercode it is possibility to make all what it is possibility in C or C++.. and mutch more..
Look, all Plugins be rewrite since 3.0 and so.. you can/have possibilitys to start rewrite the firefox totaly new ...

nest regards
Blacky

Comment #11.1 by: juan on 20 Dec 2011, 21:30 GMT

What?


Comment #12 by: NonyaEffinBizness on 12 Jan 2012, 08:48 UTC reply to this comment

What's the need to come up with a new version every other day? I'm still using version 3.6.25 because some of the addons I use aren't compatible with newer versions. I guess it's time to move on to Chrome.

Comment #12.1 by: Lucian Parfeni on 12 Jan 2012, 09:14 GMT

A new Chrome comes out just as often as a new Firefox. What's more, in Firefox 10 all add-ons will be compatible by default, bringing it on par with Chrome.
It is however the responsibility of the developers to make sure their add-ons work and to keep them updated. This is especially true if add-ons made by lazy/bored/busy developers are keeping people from upgrading to a newer and better browser. The same thing applies to Chrome add-ons.

Copyright © 2001-2012 Softpedia. Contact/Tip us at

WindowsGamesDriversMacLinuxScriptsMobileHandheldNews

SUBMIT PROGRAM   |   ADVERTISE   |   GET HELP   |   SEND US FEEDBACK   |   RSS FEEDS   |   UPDATE YOUR SOFTWARE   |   ROMANIAN FORUM