Segmentation Fault or bad alloc() why do they occur?? The former occurs for the so called stack allocation when the stack memory runs out for the process and the pointer points elsewhere. The latter occurs for heap allocation when there is not enough free pages available to be satisfy the requested size. I know stack and heap are subjective in nature but lets call them that for the time being.
However, are we not supposed to think that mechanisms like virtual memory and swapping allows us to essentially use the real memory + the disk as the effective memory that we can use? The disk can be again be subjective as in Linux it can refer to a swap partition or a swap file, but lets hypothesize that we can allocate it so that it possibly can use the entire disk. Then again why do we run out of memory so easily when modern disks are so huge in size. And where exactly does virtual memory play a role?
I had been baffled by all these questions sometime back when I was trying to research a new sort of memory allocator. This blog, “Out Of Memory” Does Not Refer to Physical Memory" by Eric Lippert gave me further insight into the matter at hand. He says that the entire memory for a process can be thought of as a file on disk and the RAM as a mere performance enhancement, a sort of cache. If you think about it this way a lot of problems goes away. But then again if memory is really a file on disk, then when do we run out of memory? Is it when we run out of disk space? That can't be possibly right, can it?
We run out of memory when there is no more contiguous virtual memory address space to allocate to the requesting entity. In processors that provide disparate virtual address spaces to processes, the entity usually refers to threads. If that is in fact true, then running out of space is more of a misnomer, is it not?
Should it not be called running out of virtual memory address space.
Also the exception "Out of Memory" should be revised to be called "Out of Contiguous Virtual Address Space"
Note: Whenever I talk about a language, it is almost always C++. Beg your pardon for any confusions
However, are we not supposed to think that mechanisms like virtual memory and swapping allows us to essentially use the real memory + the disk as the effective memory that we can use? The disk can be again be subjective as in Linux it can refer to a swap partition or a swap file, but lets hypothesize that we can allocate it so that it possibly can use the entire disk. Then again why do we run out of memory so easily when modern disks are so huge in size. And where exactly does virtual memory play a role?
I had been baffled by all these questions sometime back when I was trying to research a new sort of memory allocator. This blog, “Out Of Memory” Does Not Refer to Physical Memory" by Eric Lippert gave me further insight into the matter at hand. He says that the entire memory for a process can be thought of as a file on disk and the RAM as a mere performance enhancement, a sort of cache. If you think about it this way a lot of problems goes away. But then again if memory is really a file on disk, then when do we run out of memory? Is it when we run out of disk space? That can't be possibly right, can it?
We run out of memory when there is no more contiguous virtual memory address space to allocate to the requesting entity. In processors that provide disparate virtual address spaces to processes, the entity usually refers to threads. If that is in fact true, then running out of space is more of a misnomer, is it not?
Should it not be called running out of virtual memory address space.
Also the exception "Out of Memory" should be revised to be called "Out of Contiguous Virtual Address Space"
Note: Whenever I talk about a language, it is almost always C++. Beg your pardon for any confusions
