From: ····@su-russell.UUCP
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Date:
Message-ID: <253@su-russell.ARPA>
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.).
From: ·····@utah-orion.UUCP
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Date:
Message-ID: <149@utah-orion.UUCP>
In article <···@su-russell.ARPA> ····@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