Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!husc6!ut-sally!utah-cs!utah-orion!shebs
From: shebs@utah-orion.UUCP
Newsgroups: comp.lang.lisp
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Message-ID: <149@utah-orion.UUCP>
Date: Wed, 18-Feb-87 10:31:35 EST
Article-I.D.: utah-ori.149
Posted: Wed Feb 18 10:31:35 1987
Date-Received: Thu, 19-Feb-87 20:01:32 EST
References: <253@su-russell.ARPA>
Reply-To: shebs@utah-orion.UUCP (Stanley T. Shebs)
Organization: PASS Research Group
Lines: 22

In article <253@su-russell.ARPA> wade@su-russell.ARPA (Wade Hennessey) writes:

>I see no reason to support autoloading in a system which supports a
>decent implementation of virtual memory (UNIX does not fall into this
>class). A good virtual memory implementation completely subsumes
>autoloading by keeping only what you are likely to need in your
>working set (this ignores the cost of page table size, etc.).

This is yet another reason for implementors being indifferent about
autoloading.  Unfortunately, there is a tendency to shrug and assume
that "virtual memory will take care of problem X".

Virtual memories can be sandbagged by poor implementation style, such
as a high degree of internal connection.  Adding flavor to a user interface
by using kinky FORMAT options, or defining all the sequence functions
in terms of each other has severe costs in terms of paging rate.  You
also need cooperation from storage management so that GC doesn't page in
every single last byte of system code.  Lots of research has been done
on this, but there isn't even a consensus on reference counting vs GC
vs hybrids...

							stan