Virtual Memory

Question

Most of the literature on Virtual Memory point out that the as a Application developer,understanding Virtual Memory can help me in harnessing its powerful capabilities. I have been involved in developing applications on Linux for sometime but but didn't care about Virtual Memory intricacies while I code. Am I missing something? If so, please shed some light on how I can leverage the workings of Virtual Memory. Else let me know if am I not making sense with the question!

Answer 1

You're not making sense with the question.

Answer 2

For most applications today, the programmer can remain unaware of the workings of computer memory without any harm. But sometimes -- for example the case when you want to improve the footprint of your program -- you do end up having to manipulate memory yourself. In such situations, knowing how memory is designed to work is essential.

In other words, although you can indeed survive without it, learning about virtual memory will only make you a better programmer.

And I would think the Wikipedia article can be a good start.

Answer 3

May be 9 out of 10 cases you need not worry about virtual memory management. That's the job of the kernel. May be in some highly specialized applications do you need to tweak around them.

I know of one article that talks about computer memory management with an emphasis on Linux [ http://lwn.net/Articles/250967 ]. Hope this helps.

Answer 4

Well, the concept is pretty simple actually. I won't repeat it here, but you should pick up any book on OS design and it will be explained there. I recommend the "Operating System Concepts" from Silberscahtz and Galvin - it's what I had to use in the University and it's good.

A couple of things that I can think of what Virtual Memory knowledge might give you are:

• Learning to allocate memory on page boundaries to avoid waste (applies only to virtual memory, not the usual heap/stack memory);
• Lock some pages in RAM so they don't get swapped to HDD;
• Guardian pages;
• Reserving some address range and committing actual memory later;
• Perhaps using the NX (non-executable) bit to increase security, but im not sure on this one.
• PAE for accessing >4GB on a 32-bit system.

Still, all of these things would have uses only in quite specific scenarios. Indeed, 99% of applications need not concern themselves about this.

Added: That said, it's definately good to know all these things, so that you can identify such scenarios when they arise. Just beware - with power comes responsibility.

Answer 5

It's a bit of a vague question.

The way you can use virtual memory, is chiefly through the use of memory-mapped files. See the mmap() man page for more details.

Although, you are probably using it implicitly anyway, as any dynamic library is implemented as a mapped file, and many database libraries use them too.

The interface to use mapped files from higher level languages is often quite inconvenient, which makes them less useful.

The chief benefits of using mapped files are:

• No system call overhead when accessing parts of the file (this actually might be a disadvantage, as a page fault probably has as much overhead anyway, if it happens)
• No need to copy data from OS buffers to application buffers - this can improve performance
• Ability to share memory between processes.

Some drawbacks are:

• 32-bit machines can run out of address space easily
• Tricky to handle file extending correctly
• No easy way to see how many / which pages are currently resident (there may be some ways however)
• Not good for real-time applications, as a page fault may cause an IO request, which blocks the thread (the file can be locked in memory however, but only if there is enough).

Answer 6

If you are concerned with performance -- understanding memory hierarchy is important.

For small data sets which are fully contained in physical memory you need to be concerned with caching (accessing memory from the cache is much faster).

When dealing with large data sets -- which may be paged out due to lack of physical memory you need to be careful to keep your access patterns localized.

For example if you declare a matrix in C (int a[rows][cols]), it is allocated by rows. Thus when scanning the matrix, you need to scan by rows rather than by columns. Otherwise you will be paging the same data in and out many times.

Another issue is the difference between dirty and clean data held in memory. Clean data is information loaded from file that was not modified by the program. The OS may page out clean data (perhaps depending on how it was loaded) without writing it to disk. Dirty pages must first be written to the swap file.