0
$\begingroup$

I have a question regarding multilevel page tables. As far as I know, in most 64 bit systems only 48 bits are used in page tables which would allow for 256TB of virtual memory to be addressed.

For personal computers, I don't understand how they would ever be able to support that amount of memory being virtualized. If the processes currently running on your computer think they have a total of 256TB available, if they do end up using all that memory, the contents would eventually need to be flushed back to disk. This is not possible since your disk can't possibly hold that much memory.

I'm thinking on an analogy to a bank that tells its customers they can each take out loans of 1,000 gold bars. They give their customers a note saying they have 1,000 gold bars worth of funds. Now say that the customers have used their loans to obtain different goods which they want to store in the bank. The bank would not be able to hold all those goods, and the people (processes) wouldn't be able to hold those goods either since once a computer is shut off all the memory not on disk is volatile. In a sense the bank is offering more than it can really hold.

For a more practical example, say I have 1GB of disk memory available and my virtual memory system is able to virtualize 3GB of memory. Now say I open 3 text files and start typing stuff into them, eventually reaching that 3GB limit. Now I want to save those files, but I only have 1GB available on disk!

Isn't virtual memory unreliable from a process point of view since it's saying "I can store all this stuff for you" but at the end of the day it doesn't have the resources to do so?

Improve this question
$\endgroup$
5
  • 3
    $\begingroup$ One important aspect of having a huge address space available is that it is easier to manage memory, even when you don't need all of the address space. For example, you may safely put the stack on one end of the memory space and the heap on the other, knowing that them overlapping won't be a problem (at least not before you run into other problems, like the ones you describe). Another benefit of having more address space than you actually need is that a copying garbage collector need not worry about available addresses (for instance if it decides to copy over lots of used memory). $\endgroup$
    – Andrej Bauer
    Jun 11, 2017 at 9:47
  • $\begingroup$ So I now know the total amount of virtual memory should be around the 1-1.5x the size of RAM. Say I have 200MB RAM and 1GB available on disk on a 64 bit system where only 48 bits are used for virtual memory addressing. So say I've said the max virtual memory to be allocated per process is 300MB. Does that mean a process would still be able to virtually address the addresses in range 0...2^48, or only addresses in range 0...log2(300MB)? $\endgroup$
    – MarksCode
    Jun 11, 2017 at 9:53
  • 2
    $\begingroup$ Why not? It's useful to let the process use the address space as it sees fit. So long as it doesn't cost much. $\endgroup$
    – Andrej Bauer
    Jun 11, 2017 at 12:18
  • 1
    $\begingroup$ That arbitrary constant, "64 bits", is meant to last as an upper bound of the available memory for a long time. It does not represent the amount of memory the OS has to provide (the OS can always return "out of memory" when asked more memory), but it represents an upper bound to the memory could, theoretically, provide. OSs and applications are written under that premise. Setting that limit near the current hardware limitations would only ensure that the OSs/applications must be adapted soon in the future. Recall "640KB RAM should be enough", and the absurd memory model(s) we had. $\endgroup$
    – chi
    Jun 11, 2017 at 14:50
  • $\begingroup$ @AndrejBauer But it at the end of the day the maximum amount of memory the processor will be able to use is 300MB, why not just make the total number of indexes for its virtual memory 0..300MB so it doesn't go over it $\endgroup$
    – MarksCode
    Jun 11, 2017 at 19:42

5 Answers 5

Reset to default
2
$\begingroup$

At a hardware level, virtual memory means, essentially, a mapping from a virtual address space to a physical address space, the data structures and instructions to maintain them, and a facility to trap to the operating system if a mapping is not valid. This mapping is at the page level: a page maps to a page frame.

At the operating system level, we usually conceptualise a virtual address space as a collection of segments. A segment could represent part of a file which resides on secondary storage (e.g. disk). This could be program text, or a memory-mapped file. Or it could represent anonymous memory, that is, memory which is allocated by a process and may be swapped to secondary storage if not needed. Anonymous segments are often zero-fill, which isn't backed by physical memory until it is first used. Or it could represent a memory-mapped I/O area, or an operating system device, or an operating system data structure (e.g. the "u area" in Unix).

Segments can be shared between address spaces (e.g. after the Unix fork system call). They can be copy-on-write. And so on and so forth.

There are enough "things" that can be mapped which aren't really "memory" that you can't really say that virtual address space is only as useful as the amount of physical stuff that can be mapped to it.

One more thing: Another advantage of a large virtual address space is reduced external fragmentation. You see, the segments that comprise a virtual address space need to be allocated and deallocated just like anything else, and you can't really move them within the address space. So having a large virtual address makes it easier to allocate within it.

Improve this answer
$\endgroup$
1
$\begingroup$

No. Virtual memory is reliable (typically). The OS might not let you allocate 256TB of virtual memory, unless you have a particularly beefy computer, but if it does let you allocate the memory and doesn't kill your process due to an out-of-memory situation, it is reliable.

(Separately: It's well within the realm of the possible to have 256TB of disk, even today, without inventing futuristic technology.)

Perhaps what is worth knowing is that the 48-bit address space is designed with future expansion in mind. Probably today it's unlikely that many machines will have 256TB of physical memory, or that a process will need 256TB of virtual memory. But in the future, as RAM becomes cheaper, and as data sets increase, perhaps some processes will benefit from being able to address that much virtual memory -- and the 64-bit x86 architecture is designed so it's ready for that day.

Improve this answer
$\endgroup$
6
  • $\begingroup$ I'm a bit confused. From my understanding the total amount of virtual memory an OS should be able to allocate is the total space on disk plus the total memory available in RAM. If it was able to allocate more and the processes used and filled all that memory, there would be nowhere else to put that memory! (Not to mention once those processes needed to flush to disk there wouldn't be enough room). I don't understand how the OS could be able to allocate memory of size that's magnitudes bigger than what is fully available on the machine. At the end of the day you need somewhere to put it... $\endgroup$
    – MarksCode
    Jun 11, 2017 at 5:02
  • $\begingroup$ @MarksCode, like I wrote in my answer, the OS might not let you allocate that much virtual memory. (This is OS-dependent, I think.) $\endgroup$
    – D.W. ♦
    Jun 11, 2017 at 5:13
  • $\begingroup$ Ok, so say my computer has 1GB of disk space available, and 200MB of memory (A very old computer). Shouldn't the maximum amount of virtual memory the OS could allocate be 1.2GB since otherwise it'd have nowhere to put pages it's trying to write-out/write-in? $\endgroup$
    – MarksCode
    Jun 11, 2017 at 5:14
  • 1
    $\begingroup$ @MarksCode, follow this for more on the maximum amount of virtual memory. $\endgroup$
    – fade2black
    Jun 11, 2017 at 5:27
  • $\begingroup$ @fade2black thanks. Ok so it basically confirms my hypothesis that the maximum size of virtual memory can't exceed the total disk+ram space you have. $\endgroup$
    – MarksCode
    Jun 11, 2017 at 5:45
1
$\begingroup$

Who says that the virtual memory is restricted to mapping the local file devices?

When DEC introduced the Alpha, the first mass-market 64-bit processor chip, one idea was to map the whole of any database into VM. I believe that Oracle did/does so. The key to its viability is density of references, so that a good proportion of any realised page is useful.

Similar considerations apply to the page tables themselves. You want/need associative tables that tell you fast where in real memory every active realised virtual page lives. Anything else is a waste of space.

No computer has unlimited amounts of anything. And managing virtual memory needs code: inherently imperfect. Your argument explains why it is better to write applications in C than in Java - all that unreliable JVM memory management taking up space and time. Hang on! JVM memory management is an order of magnitude more reliable than anything you or I might write in an application. Similarly, the simplicity of modelling that a large virtual memory can provide may well lead to improved reliability. If it didn't have some such benefits, it wouldn't be there.

Improve this answer
$\endgroup$
0
$\begingroup$

I don't know what you assume by non-reliable and based on what you decided the virtual memory is not reliable. In operating systems v.m. serves various purposes. This is from Wikipedia:

The primary benefits of virtual memory include freeing applications from having to manage a shared memory space, increased security due to memory isolation, and being able to conceptually use more memory than might be physically available, using the technique of paging.

Improve this answer
$\endgroup$
-1
$\begingroup$

Without virtual memory, an attempt to allocate memory can fail. You can check the documentation for your programming language etc. to find out what exactly happens in that case.

With virtual memory, when attempts to allocate memory go beyond available RAM, virtual memory will be used, which will slow things down. If you have 4 GB of RAM, and your applications require 8 GB, the memory allocations will work, but your system will slow down, eventually to the point of unusability. In practice, memory allocations won't fail - the user will just die of boredom or old age before that happens.

Beyond that, it depends on the operating system and/or which strategies it uses. For some OS, memory allocation will fail or succeed, just as with non-virtual memory. For others, allocations will succeed, and then the whole system may run out of memory if an application tries to actually use this memory.

And beyond that, well, life isn't always easy.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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