Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Argument for Virtual Memory
Message-ID: <8711151944.AA25448@cory.Berkeley.EDU>
Date: Sun, 15-Nov-87 14:44:59 EST
Article-I.D.: cory.8711151944.AA25448
Posted: Sun Nov 15 14:44:59 1987
Date-Received: Mon, 16-Nov-87 06:34:50 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 92

>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.

	If your permanent files were originally on floppy, and the VM system 
decides to remove some of them from RAM:, then what happens when you request
a file that has been removed?  You get a disk requestor.  Yucc.  Back to
square one.  Also, you cannot use this VM file system to keep, say, source
files which you are constantly updating in RAM: because the VM does not update
the floppy originally containing the source (what happens when the system
crashes?).  If it did, it means the original floppy must be in the drive
all the time anyway.

	So this VM of yours is actually a glorified disk cache.  Thank you,
I'll stick with Facc (a disk cache utilitiy).

>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
>..

	Not in a microcomputer you don't, unless you enjoy running out of
memory and disk space.

>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.

	Unless... you don't do memory management design at all.  Really
now, memory management in a calendar program?  Have you ever heard of
disk based databases?   Anything using so much memory as to need a software 
VM system will already be so large that adding the VM in software will cost
virtually nothing.

>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?

	Unload it to where?  On your hard drive?  I would want a dedicated
HD for something like that.  What do you do about shared memory?  You have
Intuition allocating Window structures accessed by N other tasks, what 
happens when the Window structure gets relocated?  I don't know of a single
program which doesn't depend on address uniqueness over all tasks in the
system.  Even DOS depends on it.  UNIX doesn't because tasks don't have
access to each other's memory spaces except under tightly controlled
conditions.  But as far as the Amiga goes, any swapping would have to go
back into the same memory block as it left.  The purpose of scatter loading 
is to allow large programs to be loaded even when memory is badly fragmented,
and doesn't apply to a VM system.

	I think a critical point here is being missed.  The question is 
simply:  Why do I want virtual memory?  The answer is always (A) memory
protection, and (B) utilization of a virtual address space larger than
physical memory.  (B) requires a dedicated hard disk for a clean 
implementation on a microcomputer.  So we have (A): memory protection.
On the Amiga, this is an extremely difficult task to accomplished because
both the OS and most application programs depend on the ability to read AND
WRITE memory 'owned' by other applications.  The issue of private vs public
memory is nice in concept, but useless in reality because most objects need
to be public anyway. 

	Falling back onto (B).  Utilization of a virtual address space larger
than main memory is easily supported by the Amiga, but you need a 68020
to do it (the 68000/68010 has only a 16Mbyte address space and most of that
is already assigned.)  What one would have to have on the Amiga (68000) would
be a couple of virtual object allocation system calls...  allocate, lock,
unlock, and deallocate.  You allocate an object of X bytes and get a key for
that object.  The object may or may not be in memory.  By locking the object
you get an actual pointer to the object and may read/write it.  By
unlocking the object you inform the OS that it can move the object out of
memory if memory gets tight.  You need to lock the object before you can
access it again.  With VM being tightly controlled in this way, objects
can be shuffled around in memory and need not occupy one absolute location...
but ONLY while the object is not locked and thus is not in use.

	Such a VM system would be distinguished from real memory.  That is,
unlike a real paged VM system, each task has full control over when an
object is or is not in physical memory, or can use the normal memory allocation
routines to get permanent memory (aka AllocMem()) with low overhead.

					-MDari