Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Firefox Mozilla Upgrades News

Firefox Is Going 64-Bit: What You Need To Know 364

Posted by Soulskill
from the hands-extended-and-upturned dept.
An anonymous reader writes "Firefox product manager Asa Dotzler determined that figuring out the 64-bit confusion surrounding Firefox it will be 'near the top' of his to-do list this summer and fall. One could conclude that Mozilla has no idea at this point what people are expecting from a 64-bit version of Firefox, so Dotzler is asking for some feedback. More speed? More security? What about plug-in availability? All of the above, please."
This discussion has been archived. No new comments can be posted.

Firefox Is Going 64-Bit: What You Need To Know

Comments Filter:
  • Then why make a 64 bit version at all? If the company has no idea what people expect, then they don't need to be messing with it in first place.
    • Memory! (Score:5, Funny)

      by Oxford_Comma_Lover (1679530) on Saturday July 16, 2011 @12:53PM (#36787244)

      Then why make a 64 bit version at all? If the company has no idea what people expect, then they don't need to be messing with it in first place.

      Hurray! With 64 bits, Firefox might be able to address all the memory it uses...

      • Re: (Score:3, Insightful)

        by grub (11606)

        Hurray! With 64 bits, Firefox might be able to address all the memory it uses...

        Firefox and the OS will still need ZFS' 128 bit filesystem for the swap space.
      • Re:Memory! (Score:5, Funny)

        by TheLink (130905) on Saturday July 16, 2011 @01:39PM (#36787600) Journal
        More like it'll be able to leak more than 4GB of memory.
    • by fuzzyfuzzyfungus (1223518) on Saturday July 16, 2011 @01:13PM (#36787430) Journal
      (Easy) compatibility with 64-bit plugins and not having to drag along a whole bloody system's worth of 32-bit libraries just to install the browser seem like the most evident reasons...

      What confuses me is why they would be framing an address-length change in terms of additional features. With the specific exception of applications where the implementation of certain features requires easy access to gigantic slabs of memory, there isn't a whole lot of connection between 64-bitness and the feature list.
      • I was thinking the same thing, so I looked into it a bit (no pun intended). Apparently "true" 64-bit processing uses a more modern instruction set on the CPU, so I suppose there are additional performance and security benefits to using it.

        • by dougmc (70836)

          Apparently "true" 64-bit processing uses a more modern instruction set on the CPU, so I suppose there are additional performance and security benefits to using it.

          x86_64 has more registers than x86 (i386, 32 bit) so that can give a significant performance increase in some situations. (Note that this is not directly related to being 64 bit vs 32 bit -- it's simply having more registers with the more modern instruction set, as you put it.) Being able to do operations 64 bits at once rather than 32 bits at once speeds things up as well if the program is written to use it (and of course, this IS all about 64 bit vs 32 bit.) On the down side, pointers are larger and s

      • by Malc (1751)

        Compatibility with 32-bit plugins seems like a good idea. Then they can switch to 64-bit browser without causing users hassle. For instance, they already run Flash in a separate surrogate process, so with the right interface, it shouldn't matter whether the Flash plug-in is 32 or 64 bit. And yes, I've taken this approach on Windows via COM/DCOM to make unportable 32 bit DLLs available to 64 bit applications. Can XPCOM or whatever Mozilla uses handle this kind of thing?

        • At least on the Linux side, I know they've had some sort of shim setup for running 64-bit FF with 32-bit Flash for a while now. I don't know the dirty details of how it works, and what, if any, unpleasant side effects it has.
        • by Anaerin (905998) on Saturday July 16, 2011 @03:37PM (#36788452)

          At the moment, 64-bit FireFox will only run 64-bit plugins (As I know, running Windows FireFox Nightly 7.0a1 x64 as my default desktop browser, And there are 64-bit plugins on Windows for Java and Flash). They're working on it, though. [mozilla.org]

          And most of the memory leaks are being caused by poorly-written or resource intensive plugins (Like FireBug), and they're working on that, too. "about:memory" in nightly builds now lists a complete tree of what's using the allocated memory, and more reporters are being introduced all the time.

    • by WrongSizeGlass (838941) on Saturday July 16, 2011 @02:05PM (#36787772)

      Then why make a 64 bit version at all?

      Maybe they need an excuse to change the version to 6.4?

    • Cuz 32-bit version runs out of memory when you have it open for several days and 100's of windows/tabs?

      Cuz, the 32-bit version doesn't work well on 64-bits because it isn't aligned right and suffers terrible performance penalties?

      (during a bogdown today, where it had it's cpu 'peg'ed...(why the windows threading model doesn't support multiple cpu's is ... well, linux really lucked out in choosing their 1thread/proc model)
      Here's the stack trace:

      0) ntoskrnl.exe!memset+0x64b
      1) ntoskrnl.exe!KeWaitForMultipleObj

  • by chrylis (262281) on Saturday July 16, 2011 @12:53PM (#36787236)

    Perhaps if they instead focused on fixing the memory leaks, pushing out 64-bit builds wouldn't be so pressing an issue?

    • by TheRaven64 (641858) on Saturday July 16, 2011 @01:07PM (#36787390) Journal
      64-bit is important because an increasing number of operating systems are no longer shipping 32-bit libraries by default, and on the ones that are, most apps are 64-bit so they may not be swapped in. On this machine, only four of the apps that I'm running are 32-bit - and two of those are just because I'm running really old versions and haven't bothered to upgrade (they're open source and 32-bit clean). With these running, I have a lot of libraries loaded twice, once for them and once for every other application. A couple of years ago, the balance was in the other direction - a few 64-bit apps and a lot of 32-bit ones. If FireFox is the only 32-bit app that you're running, then that's a huge amount of 32-bit shared library code that is loaded solely for FireFox's benefit.
      • by PopeRatzo (965947) *

        32-bit clean

        What does it mean when you say something is "32-bit clean"?

        • by Osgeld (1900440)

          I cant speak for the op, but I have not heard that term in a while ... in a nutshell you can take your 16/18/24 bit app (depending on what it was running on) and shoehorn it into 32 bit space if you had a bitchy OS/System that could not deal with it

          though the last time anyone had a real issue with it was in the early 90's as mac's have been 32 bit since the (very) late 80's and MS finally went (full)32 bit with windows 95

          • by siride (974284)

            When was the last time you used an 18-bit application?

        • by chammy (1096007)
          They don't do things in the source code that would break when you compile under 64bit, like cast pointers to ints or something.
      • by BitZtream (692029)

        Other than some random Linux distro, name an OS that has 'stopped shipping 32bit libraries' by default.

    • No need to fix FF's memory leaks.

      Having a 64 bit version will all FF to take advantage of more than 4 GB of memory.

      Fixing leaks is a waste of effort on mozilla's part. If you had a boat with leaks would you waste time, effort and money to fix it? No. Just get a bigger hull.
    • Releasing a 64-bit install is about compatibility in the environment. But an implication by the parent is that Mozilla can't work on increasing compatibility and fix bugs at the same time. These two things aren't related at all where we should welcome things like this.

      Or another way to think about it: We should applaud Mozilla for releasing the 64-bit installer and continue to complain about the bugs.

  • Oh great. (Score:5, Funny)

    by MaxBooger (1877454) on Saturday July 16, 2011 @12:59PM (#36787300)
    64-bit Firefox: Now with 192 gigabytes of memory leaks!
  • Eh? (Score:4, Insightful)

    by jmorris42 (1458) * <jmorris@@@beau...org> on Saturday July 16, 2011 @01:02PM (#36787344)

    I thought I had been running a 64bit Firefox for years. So I wasn't? Or is this about finally doing a 64-bit Windows build? Probably since Moz Corp is entirely focused on Windows and treats Linux as a red headed stepchild.

    • >I thought I had been running a 64bit Firefox for years.
      I know I have. First third party SeaMonkey builds, then the SeaMonkey Nightlies got 64 bit options, and I went to that.

    • Re:Eh? (Score:5, Informative)

      by kripkenstein (913150) on Saturday July 16, 2011 @02:31PM (#36787954) Homepage

      I thought I had been running a 64bit Firefox for years. So I wasn't? Or is this about finally doing a 64-bit Windows build? Probably since Moz Corp is entirely focused on Windows and treats Linux as a red headed stepchild.

      I am a Firefox dev and a Linux user. Mozilla is definitely not focused on Windows, in fact many of us devs use Linux (I am posting from Ubuntu right now), and many of the rest use OS X. Windows is in the minority.

      There are 64-bit builds available from our build system, but we don't promote them. The reason is that we don't spend as much effort on QAing 64-bit builds, we have limited resources and are focused on the standard (32-bit) builds for the most part.

      There are some good reasons for 64-bit browsers, for sure, but AFAIK none of the major browsers make that a priority. For example, there is a 64-bit IE9, however it ships with a hobbled JavaScript engine (without JITs), so clearly they don't intend it very seriously.

      In any case, given that Firefox is open source, anyone can build a 64-bit version. I believe several Linux distros ship a 64-bit Firefox, for example. There used to be some problems with running 32-bit Flash in it, but I have heard that is workable now too.

      • by Teun (17872)
        I'm presently running the 64bit flash 11.0.1beta in Firefox on Linux.

        It has some issues but for the majority it works.

        Can you point to such a Firefox 64bit build?

        • by Teun (17872)
          Ah, the Linux version IS 64bit, could have thought of that one myself...
        • Can you point to such a Firefox 64bit build?

          Sure, Mozilla's ftp server has them here [mozilla.org] (the ones with x86_64). Those are for FF8 (Nightly build).

    • by gilesjuk (604902)

      If I view the process in Activity Monitor on OSX it says Firefox is 64-bit anyway.

      So I don't understand what they are announcing?

  • The OS X version is 64 bit already. At least, I can choose whether to launch it in 32- or 64-bit mode.

  • by KiloByte (825081) on Saturday July 16, 2011 @01:10PM (#36787416)

    What's the problem with 64 bits? Firefox worked just fine with it for years. Unless you're using a doorstop machine or a doorstop OS, even having 32 bit libraries is a waste of disk space. Heck, even phones start having 2GB ram, suggesting ARM will need to transition soon. MIPS (Longsoon) is already there.

    When project electrolysis finally lands on Firefox trunk, the only current benefit of 64 bits will be gone, but that's still not a reason to have a complete set of 32 bit libraries in memory (or even on disk).

    Limits of 32 bits are annoying. For example, gcc-4.6 can partition flto compilation but it still needs to load everything into the memory. It'd be a huge waste of programming time to implement your own swapping if the OS is perfectly capable of doing that. If the address space is big enough, that is. You currently cannot compile Firefox with flto on a 32 bit machine at all, and it gives a huge (~20%) boost on typical C++ code.

    Thus, your precious 32 bit systems are a doorstop architecture that would be nice to get rid of.

    • by hedwards (940851)

      The short answer is that there is no reason to move to 64-bits, and distros that drop the 32-bit libraries by default really shouldn't be doing so. This isn't like the move from 16-bit to 32 bit where most applications would benefit from the extras. In this case you end up using more memory whether or not you get any benefit from it and there's a ton of applications which just don't benefit from the extra bits.

      Oddly enough, a browser really should be one of the things that stays at 32bits.

      • by KiloByte (825081)

        Why would I install two distinct architectures instead of just one?
        Heck, I see a reason to have amd64 and armel co-installed so you can easily cross compile and test things, but amd64 and i386? What for?

    • by Viol8 (599362)

      "Limits of 32 bits are annoying. For example, gcc-4.6 can partition flto compilation but it still needs to load everything into the memory"

      Wtf are you compiling that you need more than 4GB of virtual memory? The whole of Windows 7?? Sounds like you're BSing to me.

  • History repeats (Score:5, Insightful)

    by Wonko the Sane (25252) * on Saturday July 16, 2011 @01:18PM (#36787478) Journal
    This sounds like like the, "Why should we rewrite our perfectly good 16 bit applications just because everybody else is jumping on the 32 bit bandwagon" conversations that we went through back in ancient times.
    • by msobkow (48369)

      Funny thing. I don't remember any arguments at all when the shift was 8-bit to 16-bit. :)

  • Firefox 64bit - now capable of completely glooping 2 exbibytes! At current rate of leaking, this means you now only need to restart one a day! (Warning, depending on speed of swap device, Firefox 64bit may take more than a day to restart.)
  • This entire article makes no sense.
    We simply want a version of Firefox that takes advantage of the additional resources our 64-bit machines have.
    Sure there are probably specific optimizations you can do, but really the most important thing is simply to compile it to a 64-bit program instead of the x86 they use currently.
    Can someone explain to me why anyone would think differently?

    • by hedwards (940851)

      My prediction is that this is more about window dressing. There's a lot of people out there that assume that 64-bits are always better than 32-bits and that if I paid for a 64-bit processor I want to run everything possible in 64-bits.

      Probably the only reason to ever create a 64-bit processor is for platforms that don't have the 32-bit libraries. But, you add a lot of overhead and for something like a web browser you don't really gain much if anything in terms of performance.

      In the long run, I bet this will

      • What?

        I do not normally like to contradict someone in a technical field such as this one unless I am a really big expert (but I have looked into 32 vs 64 bit quite a lot) in that field but I am pretty sure everything you have just said is complete crap.

        64 bit has many many benefits above and beyond the obvious and very nice ability to use more RAM and execute bigger instructions.
        But no I have seen no evidence nor heard anyone who seemed to know what they were saying say that it uses significantly more RAM.
        If

  • Here's an idea. How about not breaking add-ons with every new version? That would be great!

    I'm in the Firefox beta program, so they FORCE me to upgrade over and over and over again (really obnoxiously). And every single time, Firebug and Greasemonkey stop working. Problem is, I need Firebug, in particular, to do my job, so it's inconsiderate at the very least, a horrible way to treat your beta testers. And yet, much of my coding is in preparation for HTML5, so I need to use what's in the beta too.

    So
  • Firefox has been available as 64 Bit for years. The article is about 64-bit WINDOWS.
  • Hasn't a linux 64 bit version been available for a few years now?
  • by roman_mir (125474) on Saturday July 16, 2011 @02:36PM (#36788002) Homepage Journal

    they truly needed that, because soon enough they'll run out of 32 bit integers they use for version numbering.

  • Pale Moon is already available for people to check out. It's Windows-only, but I've been running it for a while as a secondary browser at work, and it works pretty well, albeit with a few minor quirks.

  • Fix the damn UI Hanging issues, get ASLR fully working along with DEP and full process isolation before adding stupid features and Don't forget multithread support working correctly.

    I'd much rather they fix these issues while moving towards 64bits as these alone should improve the damn stability and security. Hell if a damn Add-On hangs or creates problems, I'd love to be able to kill the thread/process that's hung instead of shuting down the entire app.

Stinginess with privileges is kindness in disguise. -- Guide to VAX/VMS Security, Sep. 1984

Working...