Path: utzoo!attcan!uunet!mcvax!jack
From: jack@cwi.nl (Jack Jansen)
Newsgroups: comp.arch
Subject: Re: Today's dumb question...
Message-ID: <327@piring.cwi.nl>
Date: 18 May 88 20:20:43 GMT
References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP> <674@cernvax.UUCP> <9558@sol.ARPA> <53@daitc.ARPA>
Organization: AMOEBA project, CWI, Amsterdam
Lines: 27

In article <53@daitc.ARPA> jkrueger@daitc.UUCP (Jonathan Krueger) writes:
[Giving reasons for virtual memory]
>avoiding memory fragmentation - virtual memory management provides a
>way for multiple processes to share the physical store, cleanly and
>without performance bottlenecks.

Not providing virtual memory doesn't mean that segments in memory
needs to be contiguous. There might be a point for copy-on-write
or zero-fill-on-demand, but I'm not sure that only these are worth
the trouble.
>
>preventing unnecessary i/o - virtual memory systems need not load in
>an entire image, thus performing fewer disk-to-memory reads per
>execution, an advantage in a development cycle, among other places.

Again, given heaps of memory and fast communication this doesn't
matter anymore. If my file server can keep a copy of emacs in it's
cache and download it with 700Kb/s I'm up and running in a second.
Quite acceptable, I think.

Of course, there will always be applications that *do* benefit from
virtual memory, but I guess within reasonable time VM will fall in the
same class as vector processors or other esoteric features that can
be found on specialized machines, not on everyday workstations.
-- 
	Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
	The shell is my oyster.