🚀 go-pugleaf

In article <7621@tekecs.UUCP> kendalla@blast.UUCP (Kendall Auel) writes:
>In article <1162@ncr-sd.UUCP> greg@ncr-sd.UUCP (Greg Noel) writes:
>> ... Perhaps more to the point would be to say that the memory image seen by
>>     the program is independent of the real memory provided by the machine.

>I had always thought that virtual memory meant address translation only, and
>that a memory hierarchy (cache, RAM, disk, tape, ...) did not necessarily
>exist in a virtual memory system.

This is true.  In fact, I have seen a design for an embedded computer with no
backing store that used virtual memory to improve its real memory utilization.
The tasks ran in a largish virtual space and the unallocated memory simply
wasn't mapped.  The memory allocator had some heuristics to minimize the number
of pages occupied and didn't hesitate to leave large sections of the virtual
memory unused and unmapped.  Typically, fragmentation causes you to run out of
space when there is as much as one-third of the memory still available (see
Knuth, Vol. I for details); with this scheme, we could depend upon functioning
with over 90% utilization, and often over 95% -- it was like adding half again
as much memory......

I wish my Amiga used this trick; it's irritating to run out of memory when
the system claims that it still has 220K free.......

>When I looked it up, however, my textbooks
>speak of virtual memory as a way to map backing store into the address space
>of the processor:  [.... quotes deleted .....]
>
>I got two points from this reading. 1) Virtual memory *technically* implies
>only address translation, and 2) The main advantage to using virtual memory
>is to extend physical memory via a backing store (disk, drum, ...). Thus, the
>concept of virtual memory for all intents and purposes implies swapping memory
>to and from a disk, as well as address translation.

An accurate assessment, I think.  Although there are reasons to separate the
two concepts, they work so well together that it is hard to consider them
independantly.
-- 
-- Greg Noel, NCR Rancho Bernardo    Greg@ncr-sd.UUCP or Greg@nosc.ARPA