I get that 2^32 = 4,294,967,296 and 2GB is for the OS and 2GB is for the process, but why does a 64 bit OS only give 4GB of address space? Should it not be 2^64 = 18,446,744,073,709,551,615 which when divided evenly amongst the OS and process is a lot more than 4 GB?

  • 7
    You should clarify that you're talking about the address space available to 32-bit processes. 64-bit processes have access to much more than 4GB of address space. – David Schwartz Dec 29 '11 at 0:51
  • 1
    A 32-bit application on a 64-bit operating system is subject to exactly the same limitations as a 32-bit application on a 32-bit operating system, all the operating system structures required by the 32-bit application are the same. The only applications that see true benefits with 64-bit are the operating system itself and 64-bit applications. – Mokubai Dec 30 '11 at 0:27

If you look at Memory Limits for Windows Releases

The limit for x64 user mode virtual address space is not 4GB but at least 8TB

Some explanation that justifies the 8Tb limit.

By default a 32bit exe is limited to 2GB on 64bit os as well unless it is tweaked with IMAGE_FILE_LARGE_ADDRESS_AWARE

  • 3
    Note that 64-bit processes must set IMAGE_FILE_LARGE_ADDRESS_AWARE in their PE header to get that much user mode virtual address space, otherwise they're limited to 2 GB like 32-bit processes. – afrazier Dec 29 '11 at 4:08

2^32 (4GB) is the maximum amount of address space that can be addressed at one time with 32-bit pointers. So a 32-bit process is necessarily limited to an address space of 4GB, because it uses 32-bit pointers, regardless of OS.

Note that this is purely a restriction on virtual memory that a process can have mapped into its address space at one time.

  • why is 2 gig the limit? a 32 bit pointer can address 4 gigs of memory directly. I read a page that said you have to be careful doing pointer math on pointers with the high bit set, but other than that, why would there be a limit of 2 gig? Nobody seems to know "WHY?" – Stu Mar 10 '14 at 18:20
  • The kernel needs some address space, and it's ugly to use separate address spaces. – David Schwartz Mar 11 '14 at 2:08
  • from what I read it was to protect programmers from accidentally doing signed pointer math and getting unexpected results if one pointer had the high bit set and the other did not. Windows does not NEED 2 gigs of address space. What do you mean its ugly to use separate address space? That's what virtual memory is for. – Stu Mar 12 '14 at 10:53
  • That's the reason 32-bit processes are limited to 2GB on 64-bit editions of Windows, unless they specifically indicate that it is safe to give them a 4GB address space. 32-bit Windows does need at least 1GB of kernel address space and uses 2GB by default. It would be too complex to explain here why popular 32-bit operating systems (including Windows and Linux) don't give their kernel a separate address space and instead use a user/kernel split, but the short reason is that it makes it very complex for kernel code to interact with user space. – David Schwartz Mar 12 '14 at 11:00
  • 1
    The main reason is that if the kernel had its own address space, the TLB would have to be flushed on every kernel/user transition. Also, all data copied between kernel and user space would require remapping or windowing operations. – David Schwartz Mar 13 '14 at 17:55

Your calculations are correct. Running a 64 bit system you don't need to worry about the address space (its much more than your system will support). If the RAM size isn't what it is supposed to be, the problem lays somewhere else. Perhaps your mainboard is limiting or some of the ram sticks are not supported/broken.

  • 1
    I don't think you understood the question. – Alex Dec 29 '11 at 1:02
  • 1
    That's alright -- the OP likely didn't understand the answer. – Daniel R Hicks Dec 29 '11 at 2:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.