4 ms·

Hogging tabs in long-running Firefox instances has taught me that Windows (even 64 bit versions) still cannot address more than 3 GB of memory to 32 bit applica

Hogging tabs in long-running Firefox instances has taught me that Windows (even 64 bit versions) still cannot address more than 3 GB of memory to 32 bit applications. It used to be that was because 1 GB was reserved for the GPU, among other things. I suspect (but do not know for sure) that this is still the case.

thristian 10y ago
Originally, the top 2GB of the 32-bit address-space was reserved for the kernel, and the bottom 2GB available for each running program. This worked fairly well until programs started legitimately using 2GB of RAM, so Microsoft came up with a new scheme where only the top 1GB of address-space was reserved for the kernel, and the bottom 3GB was available for running programs. Unfortunately, they couldn't turn it on universally; there were a lot of programs that "knew" that malloc() would never return a pointer with the top bit set, so they used it as a flag for their own purposes. Such programs would break horribly in 3GB mode when pointers could have the top bit set. Also, restricting kernel-space meant the kernel had less room to do stuff; if you were running an app that was heavy on kernel-resources but light on RAM usage, 3GB mode would be a downgrade[1]. So applications have to opt-in to 3GB mode by setting a special flag in the executable, and 32-bit versions of Windows had to be put into 3GB mode at startup to support it at all. Of course, the real solution to "3GB mode at startup" is just to run a 64-bit OS, and the real solution to "2GB is not enough address-space" is to run 64-bit applications. [1]: https://blogs.technet.microsoft.com/askperf/2007/03/23/memory-management-demystifying-3gb/ https://blogs.technet.microsoft.com/askperf/2007/03/23/memor...
- ryandrake 10y ago
  > Unfortunately, they couldn't turn it on universally; there were a lot of programs that "knew" that malloc() would never return a pointer with the top bit set, so they used it as a flag for their own purposes. Such programs would break horribly in 3GB mode when pointers could have the top bit set. Fascinating story. Never knew this. This dedication to backwards-compatibility is something Microsoft was known for. Reminds me of how they took great care when writing Windows to ensure perfect compatibility with old, horrible DOS programs, going so far as re-creating DOS bugs that these broken programs relied on. I suppose they were just accepting reality: if a user upgraded to Windows and some third party program broke, the user would blame Microsoft, not the incompetent application developer.
  - adrusi 10y ago
    Both Windows and Linux are distinguished for their pathological conviction to never break userspace. Linux has its warts because of this, but since it's 10 years younger than DOS and since, as a Unix kernel, it was always very clear what the kernel should and should not do, it doesn't have quite the trail of hacks seen in Windows. Windows has broken legacy programs though. In Windows 7 a lot of old programs stopped working in the consumer editions of the OS. I don't know if they've continued making their "professional" editions that provide comparability. I suppose that's a reasonable strategy to encourage developers to update their software without killing user productivity, which could workout for the best in the long run.
    - digi_owl 10y ago
      Linux the kernel yes. but Linux user space is notoriously against dealing with backwards compatibility. As for Windows, best i can tell the problem was Win16 on 64-bit Windows. My father ran into that regarding some old solitaire programs he had been keeping around.
      - cyphar 10y ago
        Nit: There's no such thing as the "Linux userspace". The GNU/Linux userspace is a collection of many different pieces of software (including the GNU tooling and all of the FreeDesktop stuff).
        digi_owl 10y ago
        Yes, but outside of the kernel, and maybe the GNU tools, there seems to be very little willingness to entertain the need for backwards compatibility.
        cyphar 10y ago
        My issue was with the term "Linux userspace". I agree with the sentiment that many components of a modern GNU/Linux system don't seem to like the idea of backwards compatibility.
- armitron 10y ago
  Or you could have separate virtual address spaces for kernel / userland.
  - Dylan16807 10y ago
    You could, but: "Just for comparison, Linux defaults to 3 GB for user mode and 1 GB for kernel mode. There are experimental patches to implement a separate virtual address space for the kernel, thus granting 4 GB for user mode AND 4 GB for kernel mode. Unfortunately, there is a 10-20% performance hit because every system call requires an address space switch (and TLB cache flush)." Take it with a grain of salt, that quote is a decade old.
    - lokedhs 10y ago
      I wonder if this is something that is limited to a 32-bit kernel. Solaris gives each process the full 4 GB in userspace, and I think that a 10-20% performance degradation compared to Linux would be noticeable.
      - userbinator 10y ago
        It is slower. Here's an old benchmark but presumably Linux and Solaris had the same shared vs. separate address space difference back then, and the results show it: https://pdfs.semanticscholar.org/4489/18f01d17628cb94ac69f27767f74f3d6d769.pdf https://pdfs.semanticscholar.org/4489/18f01d17628cb94ac69f27... They don't call it "Slowlaris" for nothing...
gruez 10y ago
Its reserved for the kernel, not the GPU specifically. Normally the top half of the 32 bit address space was reserved for kernel use, and the bottom half for application use, but there is a flag in the PE header that tells windows to only reserve 1 GB for the kernel (and 3 GB for the application)
- Dylan16807 10y ago
  You can adjust the boot options on 32 bit windows to reserve 1GB for the kernel, or any number between 1GB and 2GB. It's irrelevant for 64 bit windows. The flag in the PE header says that the application can handle addresses over 0x80000000. It don't change reservations.
Dylan16807 10y ago
On 64 bit windows, they get 2GB by default but can opt in to 4GB. Nothing is capped at 3GB.
deleted 10y ago
[deleted]
the8472 10y ago
32bit executables can use 4GB address space on windows if they have the LARGEADDRESSAWARE flag set, which has been the case for firefox.exe since 2010[1]. It may appear that they use less than 4GB if you look at the working set or private bytes figures instead of virtual size because they reserve more address space than they allocate. Or it might crash before reaching that limit due to large allocations failing. But 64bit builds have been available for years on their ftp server, they just weren't supported. But since last december they are[2], so there really shouldn't be any need to run 32bit builds on a 64bit system. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c34 https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c34 [2] https://blog.mozilla.org/futurereleases/2015/12/15/firefox-64-bit-for-windows-available/ https://blog.mozilla.org/futurereleases/2015/12/15/firefox-6...
- acqq 10y ago
  > there really shouldn't be any need to run 32bit builds on a 64bit system Maybe the 64-bit version doesn't support the Adobe Flash plugin? The another problem with 64-bit versions is that all the pointers are twice as big. So if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application. But with 16 GB or more the 64-bit version must be better.
  - the8472 10y ago
    > Maybe the 64-bit version doesn't support the Adobe Flash plugin? 64bit flash works for me. > The another problem with 64-bit versions is that all the pointers are twice as big. You're assuming pointers dominate the footprint. if you're seeing crashes due to address space exhaustion that's more likely due to large strings/blobs of data and not a huge amount of pointers. Or to put it differently, do you really think OOM crashes are preferable to some background applications or memory-mapped files being paged out?
    - acqq 10y ago
      > You're assuming pointers dominate the footprint. No, I just wrote: >> if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application That means, I absolutely know applications that won't be better on a 8 GB RAM computer as 64-bit applications, and they were written using standard C++ libraries. Typically, such applications weren't optimized for cases when they use a lot of memory. If somebody competent spends enough time and energy, even such application can be made to use memory better but it's not something that "just happens." And sometimes 32-bits application is a good trade-off. See for example https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu... "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger." What I'm trying to suggest is that the topic is more nuanced as "64 doublegood 32."

thristian 10y ago

Originally, the top 2GB of the 32-bit address-space was reserved for the kernel, and the bottom 2GB available for each running program. This worked fairly well until programs started legitimately using 2GB of RAM, so Microsoft came up with a new scheme where only the top 1GB of address-space was reserved for the kernel, and the bottom 3GB was available for running programs. Unfortunately, they couldn't turn it on universally; there were a lot of programs that "knew" that malloc() would never return a pointer with the top bit set, so they used it as a flag for their own purposes. Such programs would break horribly in 3GB mode when pointers could have the top bit set. Also, restricting kernel-space meant the kernel had less room to do stuff; if you were running an app that was heavy on kernel-resources but light on RAM usage, 3GB mode would be a downgrade[1]. So applications have to opt-in to 3GB mode by setting a special flag in the executable, and 32-bit versions of Windows had to be put into 3GB mode at startup to support it at all. Of course, the real solution to "3GB mode at startup" is just to run a 64-bit OS, and the real solution to "2GB is not enough address-space" is to run 64-bit applications. [1]: https://blogs.technet.microsoft.com/askperf/2007/03/23/memory-management-demystifying-3gb/ https://blogs.technet.microsoft.com/askperf/2007/03/23/memor...

ryandrake 10y ago
> Unfortunately, they couldn't turn it on universally; there were a lot of programs that "knew" that malloc() would never return a pointer with the top bit set, so they used it as a flag for their own purposes. Such programs would break horribly in 3GB mode when pointers could have the top bit set. Fascinating story. Never knew this. This dedication to backwards-compatibility is something Microsoft was known for. Reminds me of how they took great care when writing Windows to ensure perfect compatibility with old, horrible DOS programs, going so far as re-creating DOS bugs that these broken programs relied on. I suppose they were just accepting reality: if a user upgraded to Windows and some third party program broke, the user would blame Microsoft, not the incompetent application developer.
- adrusi 10y ago
  Both Windows and Linux are distinguished for their pathological conviction to never break userspace. Linux has its warts because of this, but since it's 10 years younger than DOS and since, as a Unix kernel, it was always very clear what the kernel should and should not do, it doesn't have quite the trail of hacks seen in Windows. Windows has broken legacy programs though. In Windows 7 a lot of old programs stopped working in the consumer editions of the OS. I don't know if they've continued making their "professional" editions that provide comparability. I suppose that's a reasonable strategy to encourage developers to update their software without killing user productivity, which could workout for the best in the long run.
  - digi_owl 10y ago
    Linux the kernel yes. but Linux user space is notoriously against dealing with backwards compatibility. As for Windows, best i can tell the problem was Win16 on 64-bit Windows. My father ran into that regarding some old solitaire programs he had been keeping around.
    - cyphar 10y ago
      Nit: There's no such thing as the "Linux userspace". The GNU/Linux userspace is a collection of many different pieces of software (including the GNU tooling and all of the FreeDesktop stuff).
      - digi_owl 10y ago
        Yes, but outside of the kernel, and maybe the GNU tools, there seems to be very little willingness to entertain the need for backwards compatibility.
        cyphar 10y ago
        My issue was with the term "Linux userspace". I agree with the sentiment that many components of a modern GNU/Linux system don't seem to like the idea of backwards compatibility.
armitron 10y ago
Or you could have separate virtual address spaces for kernel / userland.
- Dylan16807 10y ago
  You could, but: "Just for comparison, Linux defaults to 3 GB for user mode and 1 GB for kernel mode. There are experimental patches to implement a separate virtual address space for the kernel, thus granting 4 GB for user mode AND 4 GB for kernel mode. Unfortunately, there is a 10-20% performance hit because every system call requires an address space switch (and TLB cache flush)." Take it with a grain of salt, that quote is a decade old.
  - lokedhs 10y ago
    I wonder if this is something that is limited to a 32-bit kernel. Solaris gives each process the full 4 GB in userspace, and I think that a 10-20% performance degradation compared to Linux would be noticeable.
    - userbinator 10y ago
      It is slower. Here's an old benchmark but presumably Linux and Solaris had the same shared vs. separate address space difference back then, and the results show it: https://pdfs.semanticscholar.org/4489/18f01d17628cb94ac69f27767f74f3d6d769.pdf https://pdfs.semanticscholar.org/4489/18f01d17628cb94ac69f27... They don't call it "Slowlaris" for nothing...

gruez 10y ago

Its reserved for the kernel, not the GPU specifically. Normally the top half of the 32 bit address space was reserved for kernel use, and the bottom half for application use, but there is a flag in the PE header that tells windows to only reserve 1 GB for the kernel (and 3 GB for the application)

Dylan16807 10y ago
You can adjust the boot options on 32 bit windows to reserve 1GB for the kernel, or any number between 1GB and 2GB. It's irrelevant for 64 bit windows. The flag in the PE header says that the application can handle addresses over 0x80000000. It don't change reservations.

Dylan16807 10y ago

On 64 bit windows, they get 2GB by default but can opt in to 4GB. Nothing is capped at 3GB.

deleted 10y ago

[deleted]

the8472 10y ago

32bit executables can use 4GB address space on windows if they have the LARGEADDRESSAWARE flag set, which has been the case for firefox.exe since 2010[1]. It may appear that they use less than 4GB if you look at the working set or private bytes figures instead of virtual size because they reserve more address space than they allocate. Or it might crash before reaching that limit due to large allocations failing. But 64bit builds have been available for years on their ftp server, they just weren't supported. But since last december they are[2], so there really shouldn't be any need to run 32bit builds on a 64bit system. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c34 https://bugzilla.mozilla.org/show_bug.cgi?id=556382#c34 [2] https://blog.mozilla.org/futurereleases/2015/12/15/firefox-64-bit-for-windows-available/ https://blog.mozilla.org/futurereleases/2015/12/15/firefox-6...

acqq 10y ago
> there really shouldn't be any need to run 32bit builds on a 64bit system Maybe the 64-bit version doesn't support the Adobe Flash plugin? The another problem with 64-bit versions is that all the pointers are twice as big. So if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application. But with 16 GB or more the 64-bit version must be better.
- the8472 10y ago
  > Maybe the 64-bit version doesn't support the Adobe Flash plugin? 64bit flash works for me. > The another problem with 64-bit versions is that all the pointers are twice as big. You're assuming pointers dominate the footprint. if you're seeing crashes due to address space exhaustion that's more likely due to large strings/blobs of data and not a huge amount of pointers. Or to put it differently, do you really think OOM crashes are preferable to some background applications or memory-mapped files being paged out?
  - acqq 10y ago
    > You're assuming pointers dominate the footprint. No, I just wrote: >> if you have only 8 GB of physical ram, you won't necessarily be able to handle much more than with a 32-bit application That means, I absolutely know applications that won't be better on a 8 GB RAM computer as 64-bit applications, and they were written using standard C++ libraries. Typically, such applications weren't optimized for cases when they use a lot of memory. If somebody competent spends enough time and energy, even such application can be made to use memory better but it's not something that "just happens." And sometimes 32-bits application is a good trade-off. See for example https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/ https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-stu... "A 64 bit address space for the process isn’t going to help you with page faults except in maybe indirect ways, and it will definitely hurt you in direct ways because your data is bigger." What I'm trying to suggest is that the topic is more nuanced as "64 doublegood 32."