If the size of the physical memory is given to us , can the size of the virtual memory be found out? If yes, then how?
It depends on CPU and MotherBoard. More details you can find in Gustavo Duarte's blog
No just by knowing the available RAM it is not possible to answer the question you were asked in your interview. let suppose you have 64 bit machine with 64 bit OS with 4/8/16... GB RAM. how RAM can tell the nature of OS and underlying machine. you must have at least some information about OS and architecture to give answer of the asked question
The virtual memory depends upon a number of factors. These include:
The hardware limits.
Limits imposed by your operating system (usually system parameters).
Process quota limits.
Page file size.
Related
I am learning the concept of virtual memory, but this question has been confusing me for a while. Since most modern computers use virtual memory, when a program is in execution, the os is supposed to page data in and out between RAM and disk. But why do we still encounter "out of memory" issue? Could you please correct me if I misunderstood the concept? I really appreciate your explanation.
PS: For example, I was analyzing a large amount of data (>100G) output from simulation on a computing cluster, and read in the data to an C array. Very often the system crashed and complained a memory error.
First: Modern computer do indeed use virtual memory, however there is no magic here. Memory is not created out of nothing. Virtual memory schemes typically allow a portion of the mass storage sub-system (aka hard disk) to be used to hold portions of the process that are (hopefully) less frequently used.
This technique allows processes to use more memory than is available as RAM. However nothing is infinite. Eventually all RAM and Hard Drive resources will be used up and the process will get an out of memory error.
Second: It is not unheard of for operating systems to place a cap on the memory that a process may use. Hit that cap and again, the process gets an out of memory error.
Even with virtual memory the memory available is not unlimited.
Limit 1) Architectural limits. The processor and operating system will place some maximum virtual memory limit.
Limit 2) System Parameters. Many operating systems configure the maximum virtual memory size.
Limit 3) Process quotas. Many operating system have process quotas that limit the maximum virtual memory size.
Limit 4) System resources. Notably page file space.
I thought that virtual address space was a section of RAM allocated to a specific process. But the book I'm reading says that 4 gbs is the standard limit of virtual address space. Isn't that the entire amount of RAM? If that is the case then I'm confused at what virtual address space is. Can anyone enlighten me?
That's the whole point of virtual addresses: The OS handles the physical memory, the process handles its own, virtual memory which is mapped to any memory the OS has available, not necessarily RAM.
On a 32 bit operating system the virtual address space (VAS) is, as you say, usually 4 GiB. 32 bits give you (2^32) addresses (0 ... (2^32)-1), each addressing one byte.
You could have more or less physical RAM and still have a 4-GiB-VAS for each and every process running. If you have less physical RAM, the OS would usually swap to harddrives.
The process doesn't need to know any of this, it can use the full VAS it is given by the OS and it's the OS' job to supply the physical memory.
(This is actually just a dumbed-down version of the Wikipedia article on VAS.)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I understand that the memory size that can be accessed by a 32 bit machine is limited to 4GB. Since there are I/O ports like PCIe, USB, Serial, Parallel, PS/2, Audio I/O, CD drive, floppy drive, memory card readers e.t.c that have to be dealt with as well, the result is that less than 4GB RAM is supported by the CPU itself. All the things I have just mentioned and others take quite a bit of memory also.
Now what I am confused about is how can it support several GB of hard disk space? How is it able to access even upto a 1 TB of external storage through these SATA/ATA interfaces. The same goes with the USB mass storage devices like external USB hard disks as well, I am suprised that such a big storage can be accessed by the CPU while being limited to 32 bits. Is there no limit to how big HDD can be supported by a 32 bits processor?
Not sure where to begin :-)
This is a very-very simplistic explanation, not exactly true ever since the 286, but might help you grasp basic concepts:
Memory addressing is done via an address bus: a 32 bit address bus can express 2^32 different addresses. The smallest amount of memory manipulable in one operation is called the "word" size, which is limited by the width of the data bus.
The maximum amount of addressable memory is word size times the number of addresses.
In "block IO" operations, the equivalent of the word size is the block size, usually much bigger. This is a trade-off: larger data can be accessed with the same address length, but flipping a single bit requires overwriting the whole block.
The bigger difference is that the address does not need to be present at the same time on an "address bus" like in memory: commands (and responses) are transmitted in sequential "packets", like on a network. There is thus no hardware-imposed limit on address size, albeit I am sure the protocol specifies a reasonable upper bound.
As you can see, addressable disk size is completely unrelated to CPU bus widths and register sizes.
For most nowadays application developers prefer to deal with 64 bit file pointers. For example lseek64 for linux or SetFilePointer for Windows - so from file point of view you can address 2^64 single file.
But from hardware level it is more interesting - because each disk is splitted (in logical units on clusters, in disk units on sectors). Each cluster is many bytes that can be addressed and read by single query. Operation systems hides from you these operations. But terabyte much more easily to address in terms of cluster.
A 32bit processor can handle much bigger numbers than 32bit (for example using "add with carry" instructions). The processor can write large address values into the address register of the I/O controller (for example using several 32bit data store instructions). Due to this indirect addressing the disk I/O address is independent of the processor bus address.
Is a 32-bit program running on a 64-bit OS able to use more than 4GB of memory if available?
Short answer is: yes.
Longer answer is depends. There is a hardware support for page re-mapping, which basically gives your program a window of a few pages into a larger area of memory.
This window is however, should be managed by the program itself and will not get support from memory manager. There are examples of programs doing that like SQL on Windows.
However, in general it is a bad idea and the program should either limit itself for 4GB or move to 64bits :)
Normally you're limited to a 2GB address space, in which all your allocations and their overhead, fragmentation, etc., must fit along with memory-mapped files (which includes your program and the DLLs it uses). This effectively limits you to 1.5GB.
With special configuration, e.g. /3GB, you can make more than 2GB available to applications, but by doing so you rob the kernel of space, costing you file caching, handle capacity, etc..
On Win32, you can use more with PAE support, but it's not transparent, you have to manage it yourself.
Only by explicitly mapping 4GB ranges of memory into its address space.
Under Windows Server 2003, Enterprise Edition, SP2 (/3GB switch not enabled)
As I understand it, and I may be wrong, the maximum addressable memory for a process is 4GB.
Is that 2GB of private bytes and 2GB of virtual bytes?
Do you get "out of memory" errors when the private byte limit or virtual byte limit is reached?
It is correct that the maximum address space of a process is 4GB, in a sense. Half of the address space is, for each process, taken up by the operating system. This can be changed with the 3GB switch but it might cause system instability. So, we are left with 2GB of addressable memory for the process to use on its own. Well, not entirely. It turns out that a part of this space is taken up by other stuff such as DLLs an other common code. The actual memory available to you as a programmer is around 1.5GB - 1.7GB.
I'm not sure about how you can handle accidentally going above this limit but I know of games which crash in large multiplayer maps for this reason. Another thing to note is that a 32bit program cannot use more than the 2GB address space on a 64bit system unless they enable the /LARGEADDRESSAWARE:YES linker flag.
Mark Russinovich started a series of posts on this..
Pushing the Limits of Windows: Physical Memory
While 4GB is the licensed limit for 32-bit client SKUs, the effective limit is actually lower and dependent on the system's chipset and connected devices. The reason is that the physical address map includes not only RAM, but device memory as well, and x86 and x64 systems map all device memory below the 4GB address boundary to remain compatible with 32-bit operating systems that don't know how to handle addresses larger than 4GB. If a system has 4GB RAM and devices, like video, audio and network adapters, that implement windows into their device memory that sum to 500MB, 500MB of the 4GB of RAM will reside above the 4GB address boundary.
You can only access 2Gb of memory in total (without the 3Gb switch) on 32bit Windows platforms.
You could run multiple 32bit VMs on a 64bit OS so that each app has access to as much memory as possible if your machine has more than 4Gb.
A lot of people are just starting to hit these barriers, I guess it's easier if your app is in .net or Java as the VMs happily go up to 32Gb of memory on 64bit os.
On 32 bits, if there is enough physical memory and disk space for virtual memory, memory runs out around 3GB since the kernel reserves the address space above 0xC0000000 for itself. On a 64 bits kernel running a 64 bits application, the limit is at 8TB.
For more details, check out MSDN - Memory Limits for Windows Releases
Maximum addressable memory for a 32bit machine is 4GB, for a 64bit machine you can address loads more. (Although some 32bit machines have extension systems for accessing more, but I don't think this is worth bothering with or considering for use).
You get out of memory errors when the virtual limit is reached. On Windows Server 2003, task manager tells you the limit on the performance tab labelled 'Commit Charge Limit'.