Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!sdcsvax!darrell
From: darrell@sdcsvax.UUCP
Newsgroups: mod.os
Subject: Re: Who needs files?
Message-ID: <2855@sdcsvax.UCSD.EDU>
Date: Thu, 12-Mar-87 12:06:41 EST
Article-I.D.: sdcsvax.2855
Posted: Thu Mar 12 12:06:41 1987
Date-Received: Fri, 13-Mar-87 21:27:38 EST
Sender: darrell@sdcsvax.UCSD.EDU
Organization: Columbia University CS Department
Lines: 41
Approved: mod-os@sdcsvax.uucp

In article <2850@sdcsvax.UCSD.EDU> bagwill@decuac.DEC.COM (Bob Bagwill) writes:
>Some people call RAM "fast memory" and disk "slow memory" (and tape
>"very slow memory").  With large address spaces and virtual memory, who
>needs files?  Why not define all storage as extended memory structures
>that may be loaded as needed.  I realize that this is the de facto
>effect of paging systems, disk-caching, sparse addressing,
>runtime-loadable modules and workspace-oriented environments...why not
>make it de jure?

I can think of one very important distinction between virtual
memory and files.  That is, we expect file integrity to be
maintained in case of a system crash, but we don't expect this
from most virtual memory systems.  Adding facilities to a virtual
memory to insure such integrity would probably add a great deal
of overhead to normal memory accesses.

[It seems to me that what you need is the notion of a persistent data object DL]

Also, think of how big the page tables for a 2GB virtual memory
would be (if the whole 2gb space was used); that would be 2
million pages, if we have a 1k page size.  These tables would
probably be too big to remain permanently resident, and would
have to be paged, resulting in potential multiple page faults on
a simple memory access.

[The address space would be sparse (consider the IBM RT).  Also, it is not
 unusual for page tables to be paged themselves (VMS). DL]

There have actually been systems implemented which do keep all
their data in a large virtual memory.  A system called LOOM (for
Large Object-Oriented Memory) was implemented at Xerox to provide
storage for Smalltalk objects, and an object-oriented filing
system was built for the Intel iAPX-432.  I have references to
these, and can dig them up upon request.

Cheers..Yoram

Yoram Eisenstadter                     | Arpanet: yoram@cs.columbia.edu
Columbia University                    | Usenet:  seismo!columbia!cs!yoram
Dept. of Computer Science              | Bitnet:  yoram%cs.columbia.edu@WISCVM
New York, NY 10027                     | Phone:   (212) 280-8180