A Discussion of Address Space & Memory
-
I'll make some statements I believe to be true and then you can respond to each statement with true/false & reasoning. On Windows x64 (and maybe Linux too) a (normal) process 1. gets an address space which is 4GB in size when the process starts 2. OS modules take up certain portion of that address space (1GB?) 3. The rest (3GB) is used for the stack & heap of the running process 4. As the app instantiates new objects (allocates memory for objects) on the heap, the amount of memory the process uses grows -- but it can never grow beyond the 3GB (4GB total) anyways, right? 5 ## This is a biggie ## A process can never eat up more memory than its address space allows 3GB (4GB total) so a process can never really impact another process anyways because each one is limited to 4GB anyways, right? 6. Extreme Example - If there is 128GB RAM in the hardware and we say OS (associated services) take up 28GB (to make things easy) and there are two services running (2 X 4GB = 8GB) then this machine could never run out of memory, since it would have 92GB just sitting idle 7 Driving A Point Home - So when a developer notices that the app he wrote running on the Server keeps crashing with "out of memory" error, then looks around and says, "Hey, wait a second, I think your service (which has been running on the Server long before aforementioned dev's app) is eating up memory and making mine die", then that developer doesn't understand process address space, right? Right? Right! :rolleyes: This is also why A. you can solve memory problems created by lots of processes running, by installing more memory (if hardware is further expandable) B. You cannot solve memory problems of a service or app that crashes due to low memory (since it is simply eating it's own memory) by installing more memory (even if hardware is furhter expandable). Agree? Agree some? Disagree? Disagree entirely?
1 2 and 3 are true of 32-bit processes. I don't think it's true of 64 bit processes.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
1 2 and 3 are true of 32-bit processes. I don't think it's true of 64 bit processes.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Yeah, I'm very curious if a process can allocate memory beyond 3-4GB size. I saw a thing that made it look like it could :
From microsoft docs: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn[^]
384 GB or system commit limit, whichever is smaller Windows 8.1 and Windows Server 2012 R2: 15.5 TB or system commit limit, whichever is smaller.
But that seems terribly dangerous. But what do I know. Also, interested in what "system commit limit" is and if that is still set to 3-4GB on 64 bit processes.
-
Yeah, I'm very curious if a process can allocate memory beyond 3-4GB size. I saw a thing that made it look like it could :
From microsoft docs: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn[^]
384 GB or system commit limit, whichever is smaller Windows 8.1 and Windows Server 2012 R2: 15.5 TB or system commit limit, whichever is smaller.
But that seems terribly dangerous. But what do I know. Also, interested in what "system commit limit" is and if that is still set to 3-4GB on 64 bit processes.
System commit limit sounds like it might be the amount of dirty memory it can write to the swap, or maybe that it can use as swap? Not sure, but I'm more inclined to think it's the former rather than the latter, if any. Edit: I'm surprised it wouldn't be expressed in pages rather than GB though.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I'll make some statements I believe to be true and then you can respond to each statement with true/false & reasoning. On Windows x64 (and maybe Linux too) a (normal) process 1. gets an address space which is 4GB in size when the process starts 2. OS modules take up certain portion of that address space (1GB?) 3. The rest (3GB) is used for the stack & heap of the running process 4. As the app instantiates new objects (allocates memory for objects) on the heap, the amount of memory the process uses grows -- but it can never grow beyond the 3GB (4GB total) anyways, right? 5 ## This is a biggie ## A process can never eat up more memory than its address space allows 3GB (4GB total) so a process can never really impact another process anyways because each one is limited to 4GB anyways, right? 6. Extreme Example - If there is 128GB RAM in the hardware and we say OS (associated services) take up 28GB (to make things easy) and there are two services running (2 X 4GB = 8GB) then this machine could never run out of memory, since it would have 92GB just sitting idle 7 Driving A Point Home - So when a developer notices that the app he wrote running on the Server keeps crashing with "out of memory" error, then looks around and says, "Hey, wait a second, I think your service (which has been running on the Server long before aforementioned dev's app) is eating up memory and making mine die", then that developer doesn't understand process address space, right? Right? Right! :rolleyes: This is also why A. you can solve memory problems created by lots of processes running, by installing more memory (if hardware is further expandable) B. You cannot solve memory problems of a service or app that crashes due to low memory (since it is simply eating it's own memory) by installing more memory (even if hardware is furhter expandable). Agree? Agree some? Disagree? Disagree entirely?
For Linux and friends, start with
man getrlimitandapropos oom. The whole OOM-killer environment is intriguing, to say the least. I believe it came from the *nix legacy of lots of users timesharing a machine with limited resources, particularly memory. A competitive, rather than cooperative, workload.Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
Yeah, I'm very curious if a process can allocate memory beyond 3-4GB size. I saw a thing that made it look like it could :
From microsoft docs: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn[^]
384 GB or system commit limit, whichever is smaller Windows 8.1 and Windows Server 2012 R2: 15.5 TB or system commit limit, whichever is smaller.
But that seems terribly dangerous. But what do I know. Also, interested in what "system commit limit" is and if that is still set to 3-4GB on 64 bit processes.
Step away from the misbehaving application for a moment. Fire up a VM running the Windows OS you want, and write a bad, evil application. It does not have to be complex. Using a VM allows you to crash/hang it instead of your main box. Try malloc (comes off the heap) and static allocation (process space?). I'm rusty. Just play around. That said, trust nothing Microsoft "documents." I fully confess that I am jaded. Trust but verify. I have had my left leg in the embedded world and the right leg on the desktop. My two common errors has been buffer overflows into malloc'd areas and stack overflows. Either way, it's an application issue. Keep learning.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Yeah, I'm very curious if a process can allocate memory beyond 3-4GB size. I saw a thing that made it look like it could :
From microsoft docs: Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn[^]
384 GB or system commit limit, whichever is smaller Windows 8.1 and Windows Server 2012 R2: 15.5 TB or system commit limit, whichever is smaller.
But that seems terribly dangerous. But what do I know. Also, interested in what "system commit limit" is and if that is still set to 3-4GB on 64 bit processes.
I need to amend my earlier statement about 32-bit processes under Windows. While it's not important, historically the process address space was divvied such that the lower 2GB was "user space" and the upper 2GB was "kernel space" (I may have that backward, but either way, it's half and half) Some apps could be "3GB aware", sometimes run with a command line switch like /3GB to enable it. In that case, the kernel was only mapped to 1GB of the address space. I'm not sure why all apps weren't this way, other than compatibility. An example of a 32 process that could be 3GB aware with a command line switch is the old 32-bit versions of Image Line's FL Studio DAW software.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
The 4GB limit is a Windows 32 limit, and the default in Win32 is 4 GB with 2 GB being granted the OS, effectively limiting the application to 2 GB. There is an option to make this 1 & 3 GB but I don't remember how to do this. Exchange Server and SQL Server versions designed to run on 32 bit Windows server used this option. For Windows 64, the limits are listed at [Memory Limits for Windows and Windows Server Releases - Win32 apps | Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/memory/memory-limits-for-windows-releases). Note that 32-bit applications are still limited to 4GB simply because 2^32 is 4GB. 64 bit application limits vary by OS version, generally growing with each new version of Windows.
Once upon a time Windows and x86 hardware memory management were more closely related; the hardware could be much more fully exploited. But Microsoft hoped Windows to be The OS for all different sorts of processors, so it was ported to Alpha, MIPS, PowerPC, Itanium, and I believe there were beta releases for other CPUs as well that never made it to the market. MS didn't want to build their memory management on mechanisms available on x86 only, so instead of exploiting the x86 MMS to its fullest extent, they switched to a single, flat memory space which is managed by software in several areas where x86 hardware could have been employed. x86 hardware allows a process to have a number of segments with different properties, mapped dynamically into the address space. A DLL would be a typical case of a code segment. The contents of a database could be data segment, like a memory mapped file. The sum of the data segment sizes used simultaneously by a process must fit into the 32 bit address space (without overlapping), but in principle, a process can replace one segment (code or data) with another one at runtime, if it really requires more that 4 GB of either code or data. All of it can reside in RAM; only segment descriptors are updated. Code and data are separate address spaces. Stack is a third address space. So in principle, a process could address 4+4+4 GB of memory (but the chips of the days didn't have enough address pins to allow addressing of 12 GB physical RAM). The 386 came with a mechanism for making calls to the OS that switched to the segments of the OS. So the OS also had, in principle, a 4+4+4 GB address space, which was like in a different dimension from the user space. There was no way that the user could address OS space, whether intentionally or unintentionally. The problem is that switching between user an OS mode (with a 4-ring graded protection, in addition to privileged/unprivileged instructions) that it took far too much time. MS refused to use the mechanism. Raymond Chen tells in one of his blog posts that in an MS/Intel meeting, the Intel guys asked what would be MS' highest priority for performance improvement, if only a single thing could be improved. The Intel guys though the MS answer was a joke: Faster handling of the illegal instruction interrupt. It was dead serious: Developers had identified it as the fastest way to enter privileged mode, so they used it as the basic mechanism for performing calls to the OS. They also put OS code/data and user code/d
-
I'll make some statements I believe to be true and then you can respond to each statement with true/false & reasoning. On Windows x64 (and maybe Linux too) a (normal) process 1. gets an address space which is 4GB in size when the process starts 2. OS modules take up certain portion of that address space (1GB?) 3. The rest (3GB) is used for the stack & heap of the running process 4. As the app instantiates new objects (allocates memory for objects) on the heap, the amount of memory the process uses grows -- but it can never grow beyond the 3GB (4GB total) anyways, right? 5 ## This is a biggie ## A process can never eat up more memory than its address space allows 3GB (4GB total) so a process can never really impact another process anyways because each one is limited to 4GB anyways, right? 6. Extreme Example - If there is 128GB RAM in the hardware and we say OS (associated services) take up 28GB (to make things easy) and there are two services running (2 X 4GB = 8GB) then this machine could never run out of memory, since it would have 92GB just sitting idle 7 Driving A Point Home - So when a developer notices that the app he wrote running on the Server keeps crashing with "out of memory" error, then looks around and says, "Hey, wait a second, I think your service (which has been running on the Server long before aforementioned dev's app) is eating up memory and making mine die", then that developer doesn't understand process address space, right? Right? Right! :rolleyes: This is also why A. you can solve memory problems created by lots of processes running, by installing more memory (if hardware is further expandable) B. You cannot solve memory problems of a service or app that crashes due to low memory (since it is simply eating it's own memory) by installing more memory (even if hardware is furhter expandable). Agree? Agree some? Disagree? Disagree entirely?
raddevus wrote:
So when a developer notices that the app he wrote running on
Presumably this is your real question and seems like it was already answered. However one somewhat related gotcha with C# (if relevant) is the Large Object Heap. Which means an app can "run out" of memory long before physical/virtual memory is used.
-
raddevus wrote:
So when a developer notices that the app he wrote running on
Presumably this is your real question and seems like it was already answered. However one somewhat related gotcha with C# (if relevant) is the Large Object Heap. Which means an app can "run out" of memory long before physical/virtual memory is used.
jschell wrote:
C# (if relevant) is the Large Object Heap. Which means an app can "run out" of memory long before physical/virtual memory is used.
:thumbsup: Both of the Apps (Services) in question are indeed written in C# and the point you make is highly relevant and I really appreciate you mentioning it. Very helpful. My question really hasn't been answered. I am still very curious if a 64 bit app can eat all of the memory on a large server (64GB RAM or something larger). I'm guessing that it cannot since 1. I believe that any app cannot allocate RAM beyond its address space. 2. This would be a huge security hole since any malicious app could just eat all RAM Someone mentioned a "leak" but even a leak is bound to the processes address space & once the process has eaten / leaked all that RAM then it would throw the "out of memory" exception. I'm just not sure if the OS allows address spaces to be much larger than 4GB and if it does what the "default" value would be for each address space on 64 bit Windows OS (Server). Very difficult thing to find. I would write an app that eats all the RAM -- and have done that, but the box I have is limited to 8GB or even 16GB and you need more RAM and running the Win Server OS to really determine this.
-
jschell wrote:
C# (if relevant) is the Large Object Heap. Which means an app can "run out" of memory long before physical/virtual memory is used.
:thumbsup: Both of the Apps (Services) in question are indeed written in C# and the point you make is highly relevant and I really appreciate you mentioning it. Very helpful. My question really hasn't been answered. I am still very curious if a 64 bit app can eat all of the memory on a large server (64GB RAM or something larger). I'm guessing that it cannot since 1. I believe that any app cannot allocate RAM beyond its address space. 2. This would be a huge security hole since any malicious app could just eat all RAM Someone mentioned a "leak" but even a leak is bound to the processes address space & once the process has eaten / leaked all that RAM then it would throw the "out of memory" exception. I'm just not sure if the OS allows address spaces to be much larger than 4GB and if it does what the "default" value would be for each address space on 64 bit Windows OS (Server). Very difficult thing to find. I would write an app that eats all the RAM -- and have done that, but the box I have is limited to 8GB or even 16GB and you need more RAM and running the Win Server OS to really determine this.
raddevus wrote:
I am still very curious if a 64 bit app can eat all of the memory on a large server (64GB RAM or something larger). I'm guessing that it cannot since 1. I believe that any app cannot allocate RAM beyond its address space.
If you by 'address space' refer to the entire 2**64 bytes space that a 64 bit process can cover by its addresses, 16 exbi bytes (more than 16 million gigabytes), your assumption is right: A process cannot allocate that much space. And we will never see a computer with 16 exbi bytes of RAM. Never ever. In no general machine (excluding e.g. embedded processors) of the last 30-40 years has the address indicated by the program code been used directly as the physical RAM address. The virtual address in the program is translated to a different physical address in RAM through a set of hardware translation tables, managed by the OS, called the Memory Management System (MMS). Each process has its own set of MMS tables. The OS sets up the MMS tables for a tiny slice of the virtual address space. If the program presents a virtual address within this slice, the range covered by the MMS tables for that process, it is translated to a physical RAM address. If the virtual address is outside the range covered by the MMS tables, an interrupt is generated, and the OS will terminate the process. (Well, it might offer a mechanism for reporting the interrupt e.g. to a debugger that can inspect the process state before it is cleaned out.) If you by 'its address space' refer to just that slice of the total 64 bit virtual address space for which the OS has set up translation tables, then you are essentially right. The size of this slice can be a few hundred kiB, a few GiB, or many GiB - but the OS will not give you more than it is capable of handling. When an app allocates RAM, the allocated space is, at the outset, within the address space translated by its MMS tables. If the malloc/new/... maps down to an OS request, the OS may say: 'There isn't enough unused space in the already mapped virtual address space, so I have to add another entry to the mapping tables, expanding the address space available to that process'. Before the OS does that, it will check that the process does not already control an excessive amount of address space. The limit is set by the OS to any value that it can handle. In many systems, malloc/new/... starts out as a call to a runtime library in the process address space. As long