Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!HERMES.BERKELEY.EDU!dillon
From: dillon@HERMES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory / doable 1.4 request
Message-ID: <8905121949.AA16989@hermes.Berkeley.EDU>
Date: 12 May 89 19:49:36 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 46


	I propose we implement a new AllocMem() flag, MEMF_VIRTUAL, in a
way that can easily be accomplished in 1.4 or 1.5 and that is fully compatible
with the current Amiga system.

	I propose that a bit in the hunk type field for an executable be
reserved to mean MEMF_VIRTUAL (allow parts of an executable's data or code 
to be loaded into virtual memory).

	I propose a common virtual store be implemented for 1.4 ... very
simple.  No per-task state stored or anything... all tasks allocate out of
the same virtual store just as they currently allocate out of the amiga's
memory.  I suggest that this would only be implemented on a 68020 or beyond 
(68000's would simply ignore the MEMF_VIRTUAL flag and allocate memory 
normally).

	Virtual memory would be demand paged to an arbitrary file on hard 
disk (arbitrary file path would allow paging over a network relatively 
easily).  Since the programmer has complete control over what is in virtual 
memory and what is not, no munging or worrying about critical sections need 
occur.

---------------- reasons

	The current direction for shared memory on unix systems is the
mmap() system call... map a file into (possibly shared) memory.  The at&t
shm() standard is a subset of mmap().  The logical next step to the above
description for the Amiga would be to allow a process to map an arbitrary 
file into virtual memory (where the file is used as swap for the VM in
question, and updated on close or unmap).

	I suggest that a logical next step would be to implement per-task
virtual memory by adding another file handle to the process structure... a
hard disk (or any other seekable) file that would be mapped into memory and
used by the process to allocate VM.  Release of memory allocated in
this way is done simply by closing the file handle.  One would also have to
allow the file system to unlink (Delete()) an open file (i.e., as in unix,
the file doesn't actually go away until all open descriptors are closed, but
the file IS removed from the directory).

	All current software would be upward compatible as it will not specify
the MEMF_VIRTUAL flag, and most of the current software will be immediately
modifiable (modify flags in the hunk type) to take advantage of sticking 
various parts in virtual memory.

					-Matt