Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!citcom!jack
From: jack@citcom.UUCP (Jack Waugh)
Newsgroups: comp.sys.amiga
Subject: Argument for Virtual Memory
Message-ID: <112@citcom.UUCP>
Date: Sat, 14-Nov-87 16:32:14 EST
Article-I.D.: citcom.112
Posted: Sat Nov 14 16:32:14 1987
Date-Received: Sun, 15-Nov-87 18:47:40 EST
References: <2785@megaron.arizona.edu>
Organization: Citcom Systems, Inc., Herndon, VA
Lines: 51

I use the "RAM:" disk driver on my Amiga computer.  I suspect everyone
does (on their Amiga).  If you move the commands you use frequently
into RAM, they will load faster.  When you have moved to a phase of
work where the files in RAM are no longer frequently used, they are a
waste of fast memory (as opposed to floppy, not as opposed to chip
memory).  So you get rid of your cached files and cache the ones you
are using now.  What you have is a system that depends on the *user* to
decide what permanent objects should be cached in fast memory and what
should not, moment to moment.  This sucks.  The computer should
automatically perform this function.  I. e., minimal virtual memory.

A user could ask for more than minimal virtual memory.  Now, the only
permanent objects on the Amiga are files and directories.  A file is a
growable sequence of mutable bytes.  A directory is a function from
names to things that are each a file or directory, with the ability to
add and delete pairs.  If the programmer wants to have data objects
that don't fit that paradigm, they cannot be permanent and must take up
the limited fast memory resource.

I would like a general mechanism, supported in some combination of
hardware and software, to support PERMANENT objects that could point to
each other arbitrarily.  In other words, a Lisp or Smalltalk-type
memory that is permanent (as in Smalltalk).  The collection of objects
should be growable to span more than one floppy.  Caching of most
recently used objects should be in RAM.  If you have a hard disk, it
would come next.  Next most recently used stuff would be on the floppy
that's usually in the drive, and the very least recently used objects
would live on other floppies.

If the memory system also organized the keeping of enough redundant
copies of everything that if any single disk got trashed, the user
would only loose at most 10 min. work, the user would be releived from
doing backups manually, too.  There is no reason that task can't be
taken care of algorithmically
(except of course loading the floppies; but that's not the
distracting part).

Such a system would make it very easy for the application programmer to
build useful things such as calendar programs, phone lists, document
editors (word processors), compilers, shells, etc. and not have the
application programming process slowed down by having to do the memory
management design over and over.

An issue with implementing such a system on the Amiga is native code
management.  A piece of native code that is to be executed must be in
primary memory (RAM).  It must also be somewhat relocated; the Amiga
has a scatter loader that does this.  A good virtual memory system
would unload such code when it is no longer in use and the memory is
more needed for something else.  Can the author of the referenced
article opposing virtual memory explain how to do this with a safe
language and compiler?