A 3GB virtual address space limit in 32-bit Windows is apparently behind the issue, causing developers to scramble for ways to work around it. Until a long-term solution is found, the Firefox team has "turned off or ripped out a few new pieces of code (Graphite, SPDY, libreg) which has brought us back down under the limit for the moment," Huey noted.
This actually isn't the first time Firefox has encountered this problem. Much the same thing happened back in early 2010, when a 2GB limit was resolved using the /3GB switch for an extra gigabyte of breathing room.
This time, however, "unfortunately the options aren't as easy as flipping a switch," Huey wrote.
Instead, the developers now face three options:
1. Remove code from the software or split code into separate shared libraries;
2. Switch to Microsoft Visual C++ 2010; or
3. Create Firefox's 32-bit builds on machines running a 64-bit operating system, thus giving the linker access to 4GB of address space.
It's not clear how much the second option would help, Huey noted, plus it won't be feasible for a few weeks. Huey recommended "a combination of (1) in the short term and (3) in the slightly less short term," he said.
SpiderMonkey, incidentally, is not part of the core "libxul" library and so is not part of the problem, Huey pointed out.
A Common Problem
Ever-advancing features pose a constant challenge to developers of most kinds of software, which tends to get bigger and bigger as a result. It will be interesting to see how Mozilla ends up dealing with it this time.
This story, "Firefox gains weight, challenging its developers" was originally published by PCWorld.