Hacker News Reader

Comment by jlgreco | Hacker News Reader

Keep in mind that this is the group that thinks de-prioritizing 64-bit windows builds is a-okay while at the same time they need 64-bit windows machines running 32-bit linkers to build their 32-bit windows binaries. ...phew, what a mouthfull.

Mozilla has never struck me as the most... forward looking.

View on HN

For one thing, I don't think their JIT produces code that properly follows the Windows x64 ABI yet. It really should be disabled in 64-bit builds until they do.

Their stated reason for de-prioritizing 64-bit builds wasn't technical; rather they say they don't have the manpower to do both. Perhaps the manpower issue is that they don't have enough people to work on the JIT issues on x64 and do everything else, but I do not believe they specified.

Following the ABI is only an issue at module boundaries. If you control every callsite of a function, you can invent whatever calling convention you want.

But you still need the function tables and follow prolog/epilog conventions with x64 for SEH to work.

btw, Google Chrome doesn't have a 64-bit version* for Windows. The Chrome team also disabled PGO on Windows because of the same MSVC linker limitations that Mozilla hit.

* Edit: oops, I corrected a typo where I wrote "32-bit build".

You mean a 32-bit build system?

Sorry, I had a typo in my post. I mean Chrome for Windows is a 32-bit application. There is no 64-bit Chrome for Windows.

Yes, though that is far less a pain in the ass since they use multiple processes. I can't count the number of times I have run out of memory with firefox on windows despite having far more than firefox was using.

Reply on news.ycombinator.com