Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!osu-eddie!paul
From: paul@osu-eddie.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Message-ID: <3197@osu-eddie.UUCP>
Date: Mon, 23-Feb-87 17:31:45 EST
Article-I.D.: osu-eddi.3197
Posted: Mon Feb 23 17:31:45 1987
Date-Received: Thu, 26-Feb-87 22:33:24 EST
References: <254@su-russell.ARPA>
Sender: news@osu-eddie.UUCP
Reply-To: paul@eddie.UUCP (Paul Placeway)
Organization: The Ohio State University, CIS Dept.
Lines: 30

In article <254@su-russell.ARPA> wade@su-russell.ARPA (Wade Hennessey) writes:
>
>Many popular operating systems do not have wonderful virtual memory
>systems. UNIX, for example, handles large processes so poorly that I
>might argue that autoloading *is* a good idea when writing a Lisp to
>run on it.
>
>Wade

No, this is not alltogether true.  Unix will handle a very large
program just fine, as long as the memory refrences are not scattered,
but are instead mostly local and/or sequential.  The problem here is
that most Lisp implementors are too lazy to carefully watch how there
lisp deals with VM.

One can, of course, give your Lisp a compacting GC, but this opens up
a whole new can of worms, including possibly, reduced GC performace...

	     -- Paul Placeway
		Department of Computer and Information Science
	SNail:	The Ohio State University
		2036 Neil Ave. Columbus OH USA 43210-1277
	ARPA:	paul@ohio-state.{arpa,csnet}
	UUCP:	...!cb{osgd,att}!osu-eddie!paul
	     -- Paul Placeway
		Department of Computer and Information Science
	SNail:	The Ohio State University
		2036 Neil Ave. Columbus OH USA 43210-1277
	ARPA:	paul@ohio-state.{arpa,csnet}
	UUCP:	...!cb{osgd,att}!osu-eddie!paul