How virtual memory works

[A Nonny Moose 8,261]

When a program is marked to be put into execution by an operating system that employs virtual memory, several things happen.  This discussion will not discuss the concepts of segmentation, but only paging.

First of all, the program is examined and arbitrarily divided into pieces of "page size", usually 4096 Bytes.  Each of these is given a (local) page number within the process number that has been assigned.

Now, if the operating system is working right (NT?  Hah!), a page table is constructed in Kernel memory, all the pages are marked absent and the processor dispatcher queue is updated so that when the program works its way to the top of the queue it can get a processor.  The starting address of the program (Process no, page no, byte no) is set as the return address for the dispatcher.

As a quick aside, the program does not, at this time, reside in memory.  It is still on disk in its original operating unit form with the page table mapped onto it.  The backing store or paging file doesn't have any of it.  (this is theoretical, because I don't think Microsoft works this way.)

When the queue in the dispatcher is updated by events in the system and the candidate program reaches the top, the dispatcher loads up the registers from the queue entry and goes to the return address.  But, but .... the program is not in memory!  Since the transfer address is through the page table, and the page table says the page is absent from memory, there is a page fault signal raised by the processor and the program is marked waiting.  It is no longer eligible for the processor, but is in  the queue  for an I/O to get the page into memory.  This is a background task of relatively high priority for the operating system.

Eventually, the page is read in, the program is put back into the dispatch queue, and comes up again, eventually.  This time, when the transfer occurs, instructions are executed in the program until either the time-slice is up, or the program tries to address a page that is not in memory, causing another merry round in the page fault routine.

Sooner or later enough of the program gets into memory to not be causing frequent page faults, and things execute up to the end of the program's time slice.  It is then put back in the bottom of the dispatch queue and something else executes for a while.  Windows, for example, updates the screen for all windows when a processor is available in this way.

Now, there comes a time when a new page of the program is needed but the allocated memory for the program has run out.  The operating system keeps track in the page table of the frequency of use of the pages in memory.  So it takes the least frequently used page, usually, and writes it on the backing store if the page is "dirty", that is has been written on.  Otherwise it just marks the page vacant (it will be got back from the original place on disk if it is needed again) and goes and gets the newly needed page.

It gets the new page from the program's operating unit if it is clean, otherwise, dirty pages are taken from the backing store.  And so it goes.

Now, there can be ants in this picnic, and we often see one or the other in SC4 when there are a lot of plugins or when real memory available is small.  If we have to swap a page and there is no place to put it because the backing store is full, this is actually a memory fault because we are out of memory.  Because the people who wrote this program chose not to do anything about it, the operating system takes the process out of execution by creating an abort with the reason of ACCESS VIOLATION, which is rather stupid, but that's what happens.

I hope this helps to clear up why some of this happens, and is not over anyone's head.  I try to be clear, but if you have questions, feel free to ask.

And yes, before you ask, I spend about thirty years teaching about operating systems, including NT.

[JakeMD 107]

thank you, you are very helpful with this kind of stuff

[wolfan10110 0]

I just got my A+ certification! W00t! However though I should feel that you also include how Vista also manages physical RAM and VRAM all together. (And before you ask, no. Vista hasn't been covered in the essentials book at all.)

[A Nonny Moose 8,261]

Originally posted by: wolfan10110 I just got my A+ certification! W00t! However though I should feel that you also include how Vista also manages physical RAM and VRAM all together. (And before you ask, no. Vista hasn't been covered in the essentials book at all.)quote>

I'm sorry if it is not clear that this is the case.  Vista still uses the NT HAL and paging stuff.  The whole memory, except the hunk marked non-paged kernel is paged, and the swap file is considered to be part of the memory, sort of.  The system knows that only some of the memory is "executable".  Of course only stuff in RAM can be executed, hence the paging system.

EDIT:  Contrats on your A+.  Hope it helps you get a job.

[High5flyier 7]

Thank you for your lesson up dates on this subject. This is why I bumped my menory up to 2GB. Months ago after you were taking about this subject I went on the net and found a little page file dfrg program. System File Defragmenter v2.32. By Mark Russenovich at SystemInternal-www..systeminterals.com. It runs at each system boot. I guess this is a good thing to do? Thank you for keeping us informed.