I thought Windows on 32 bit systems supported up to 4GB?

Just like Chrome, btw. PAE doenst help?

It’s about address space – not actual physical memory. If physical memory is a problem build would just take MUCH longer (because of constant paging) but wouldn’t fail right away.

And the article had it wrong all the way.
> PGO builds failed to complete because of a default 2 GB linker limit.

As their own link shows, it’s not linker limit – it’s 32 bit address space limit and suggested workaround was adding /3GB to the boot.ini (which allocates 3Gb address space to processes and 1Gb to kernel).

> At the time, the issue could be bypassed using the /3GB linker switch.

It’s not a linker switch – it’s a bootloader switch (passed to the kernel to actually act on).

> 64-bit Windows offers 4 GB of address space.

I’m quite sure it’s a bit more than 4Gb (http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778.aspx#memory_limits). Like about two thousand times more. And it has nice little padding on the top of this address space, so when more address space will become necessary (and when actual hardware starts supporting this) – there is a straightforward way to extend this limit.

Silly question: Can’t they just set the swap file to something like 20GB, and hence increase the available “RAM” to 23GB?

@Kurkos:

Silly answer: it’s address space. It isn’t actual physical memory. (See Linsuxoid, above.)

It sort of boggles the mind that they won’t use Visual Studio 2010, which apparently makes the problem go away for the moment. It’s even more mind-boggling that they don’t just say “OK, guys, we’re halting 32-bit development at Firefox 666.32.01a [substitute whatever yesterday’s version number was]” and move on to 64-bit development. Would anybody really care? Oh wait, they’re neck-beards on dumpster-stations … of course they would.

The usual classic comment:

“Firefox has gotten too big and bloated. No wonder Google Chrome is
gaining marketshare over Firefox.”

Yeah, that’d be the reason. Because everybody uses a browser to stress-test their RAM, don’t they? Browsing the Web is an accidental side-effect.

On the other hand, I’m struggling to see where Firefox would need 3GB of addressable space.

It seems unlikely (but not impossible) that they have quite such seriously huge fixed data structures, and the GUI (which normally chews up vast amounts of addressable space if you don’t use DLLs) really isn’t all that complex.

Presumably, then, it comes down to this wacky two-pass optimisation technique, which saves all of 10% CPU time — on the original code, on the original hardware. Here’s a suggestion for the team: TURN THE FSCKING THING OFF!

It isn’t actually the bloat that matters; it’s the selective bit-headedness.

Hmmm, looks like they use MSVC after all (so I have no idea where the Visual Studio stuff came from, unless it’s the lint-to-bootload switch). Reading through to the original 2GB problem:

“The file nsannotationservice.cpp hasn’t changed in 13 days, and Mak doesn’t think any checkins from yesterday look suspicious…

Comparing one of the broken buildlogs vs a non-broken one, the contextual lines look identical…

Perhaps we got an update to MSVC yesterday, and that broke something?”

I wish I could add italics to this.

The link failure was LNK1000 (IMAGE::BuildImage). The linker is guessing that it manifests itself somewhere near “nsannotationservice.cpp “.

Let’s ignore the obvious meaning of LNK1000.

Let’s ignore the “somewhere near” bit.

Let’s ignore any possible changes to headers included in the cpp file.

Let’s scratch our heads … OH! I KNOW! It’s gotta be the latest version of the M$ compiler!

EVIDENCE? We don’t need no stinkin’ EVIDENCE!

@ linsuxoid, I believe the 4Gb figure is referring to the limit of address space of a 32-bit process in 64-bit windows. If you build with a 32-bit compiler that applies of course

@DrLoser

“and move on to 64-bit development”

If you read the article it says that 90% of those who use Firefox use the 32-bit version, so that would kill Firefox even faster if they dumped 32-bit.

And if you read my comment I point out that you can freeze 32-bit development right now and nobody would give a dick-bird.

@ChrisTX
Ah, that makes sense.

@Ian
It’s not final product that should be moved to x64 only – it’s development. Linker does have this magic switch (http://msdn.microsoft.com/en-us/library/5wy54dk2) to allow building x86 binaries on amd64 machines and compilation should be fine anyways (they didn’t exceed the limits of the translation unit size… yet).

Still these “problems” are so dumb that I don’t even know why they are discussed at all. JUST. MOVE. TO. X64. Yes, you can’t control your customers’ hardware, but you can control yours. They should have done that “[i]n early 2010, [when] a similar problem occurred”. And by that I mean REAL x64 – not some halfassed wow64 workaround.

I also find it amusing that they still have boot.ini only “solution” (XP was the last version of Windows to use it). These guys are clearly stuck in the past. And refuse to move on. Back to caves FTW.

Pursuant to that, I am by no means an expert in MSVC development, despite working for the company.

But even I can see about three or four trivial ways out of this supposed “problem.” Heck, you can find them by simple experimentation.

What it boils down to is this: is Mozilla (or any other Loon company, for that matter) a product company or not? If so, you hire people with a common-sense attitude who do things like understanding the build environment, getting the build environment right, etc etc. Installation via an MSI wouldn’t hurt, either.

And if Mozilla aren’t a product company, it’s difficult to see what, in fact, they are. Other than a bunch of incompetent bleating sheep.

The advocate for devils, isn’t the reason for remaining on 32-bit compatibility with Adobe Flash and possibly other plug-ins?

See Linsuxoid, again, above. Build it on x64 and target it at x86. There’s even a pretty little box in Visual Studio to help you out with this.

Or alternatively freeze development on the dead-end x86 … which you’re going to have to do at some point, anyway. Are you losing market share because of it? Sh1t no.

Or alternatively LOSE THE WATCH YOUR FELCHING MOUTH OPTIMIZATION PASS!

Or alternatively or alternatively or alternatively … I’m getting all Shakespearean here.

Yes, there are still some reasons (compatibility) to run x86 browsers (and you better use x64 OS to run them), but no reason to stick to x86 development tools even though you are clearly “outgrown” them.

http://img716.imageshack.us/img716/8493/fatfox.png

“Yes, you can’t control your customers’ hardware, but you can control yours.”

Think of the source, man. The SOURCE!

“Yes, there are still some reasons (compatibility) to run x86 browsers (and you better use x64 OS to run them), but no reason to stick to x86 development tools even though you are clearly “outgrown” them.”

But but but what if a customer running a x86 OS wants to compile from source?! Is it still free if I can’t compile it because it takes too much memory to link? Don’t think so.

Y’know, I’d really like RMS’s response to that one…

These guys are awesome
https://groups.google.com/forum/#!topic/mozilla.dev.platform/wLHTg_moymM

Ehsan Akhgari wrote:
> The only real fix is for us to get a 64-bit linker. I remember some
> folks mentioning how Microsoft doesn’t have plans on shipping one
> (my memory might not be serving me well here). But really, we should
> talk to Microsoft and find this out. If they’re not planning to ship
> a 64-bit linker within the next year or so, turning PGO off is just
> something that we would have to do at some point in the future.

Er, we should talk to Microsoft? They ship amd64 linker for AT LEAST two years (VS2010 includes one). I didn’t check on earlier versions (including their beloved VS2005), but AFAIR it did have amd64 toolset too. Are 6 (or even 2) years enough for non-loon developers having problems with x86 linker (they’ve got into 2Gb limit around same time VS2010 RTMed) to figure out that their problem has already been solved? Well, definitely. Is it enough for Mozilla developers? Let’s see

Brian Smith wrote:
> Microsoft is not going to provide us with a 64-bit linker in any reasonable timeframe. We cannot switch wholesale to any other linker because we need the optimizations (including PGO) in Microsoft’s

WTF? What does that “going to provide” mean? It’s definitely doesn’t mean “included as part of already released product”. Maybe Microsoft should send them a 3.5” (or better yet 5.25”) floppies with linker on it?

Using PogsonMath™, of course, the future address space needs for Firefox are exponential. This little matter of the 8000 GB (or whatever) available under amd64? By PogsonMath™ calculations they will run out of that in, I think, five years (3^5 multiplied by what they need right now).

On the other hand, they’ll have plenty of space left over to build their 1.9 MB kernel.

Need the optimizations?

Need?

These people are idiots.

I’m curious. Have they got around to multi-threading yet, let along using parallelisation to optimise on muulti-core desktops?

I don’t think so… https://wiki.mozilla.org/Electrolysis#Status

It says they have only gotten to separating the plugins themselves (which has been there for awhile), but not rendering web content or anything.

This pact between Mozilla and Microsoft.

In terms of information transfer, it isn’t going too well, is it?

Perhaps the M$ tech department should try baby-talk; ordinary English doesn’t seem to get the message across.

Baby-talk?

Hmm… I don’t know if that would work…

How about a point blank anti tank weapon discharge?

Or, if that doesn’t “fix” the problem, a low yield nuclear device.

Come to think of it, there really is no need for the “low yield” part, they should just go with Tsar Bomba instead – it’s the only way to be sure.