Virtual Memory (a little Theory)

    Most modern machines with enormous address spaces, frequently in the range of gigabytes(!), realistically cannot contain that much core memory or mainstore. The cost simply would be prohibitive.

    The next best alternative is to make it seem to the programmer (the one who, after all, has to drive the machine) that the entire address space is physically present in the computer. This is performed using a sleight-of-hand technique known as "virtual memory".

    As the name implies, "virtual memory" looks as if it's there, but it's really not. If it's not really there, then, where the heck is it??? On disk (or some other sort of mass storage).

    Machines that support virtual memory model have two of what are known as "address spaces". These spaces represent the amount of storage that the machine posseses.

    The first of these is "Physical Address Space", or the amount of core memory actually present in the computer. The second is the "Virtual Address Space", or the amount of storage, accessible to the programmer, specified by the architecture of the machine. In the case of a DEC VAX processor the Virtual Space is equal to two raised to the 32d power, or about 4 Gb; the Physical Space is how much memory you bought for the machine.

    Almost all modern machines support the notion of memory paging, i.e. splitting up the virtual address space into nice little chunks of easily manageable size. The size of these chunks varies according to the machine in question; DEC VAXes use(d) a page size of 512 words, most UNIX boxes use pages in the 4 kb range.

    In its purest notion, a page is the smallest piece of memory that may be individually moved about conveniently (without disturbing the programs in execution).

    Since each page of virtual memory may be located anywhere within the physical address space, and will be mapped, or address translated, to its correct physical address it becomes possible for certain pages of program space (the virtual address space) to be non-resident in the physical space. If a program attempts to make a reference to one of these non-resident pages, the MMU (Memory Management Unit) alerts the operating system to the fact and the OS responds by bringing the page into core, mapping the virtual location to the physical location, and resuming the program.

    When physical memory fills to a point where it's running precariously low, the operating system makes a "judgement call" and selects infrequently used pages to be written to mass storage. These pages are then marked as "non-resident" in processes' memory management tables. The resulting free space may then be used for other active program pages.

    As with everything else, there is no free lunch. Improper use of virtual memory by a program is fantastically expensive in CPU cycles. Core memory is faster, by several orders of magnitude, than secondary storage, and the added software overhead used to drive the loading/unloading of virtual pages slows the scheme down even more. Even correct usage is quite a bit slower than if the system had sufficient physical memory present for a program's virtual space.

    Historical Note:

    Oddly enough, in the early 1980s, the notion of paging reversed itself. In the classic machines (such as the PDP-10, pdp-11, and Eclipse) the use of memory pages was to increase the amount of physical memory. For instance, the DECsystem-10 possesed a virtual address space 18 bits wide; on the KI- and KL-10, the physical address space was defined by 22 bits. This allowed many processes to remain in core at a single time (and not have to go through the "fun" of relocation).

    With the introduction of (for instance) DEC's VAX and the 32-bit machines, the model was reversed; all of a sudden a program could access a huge amount of memory, but few computer installations could afford that much mainstore. Paging then became a way to allow enormous program spaces (the virtual address) to be mapped into a much smaller physical memory space.


[ Museum Lobby ] [ Museum Catalogue ] [ Carl's Homepage ]


Copyright © 1996 - 2003, Carl R. Friend. All rights reserved.
Webspace design by: Carbon & Silicon Alliance

Comments to: carl.friend@rcsri.org
Last Modified: Sun Feb 1 11:43:29 EST 1998