From: ยทยทยท@bu-cs.UUCP
Subject: Re: autoload (was: Re: Against the Tide of Common LISP)
Date:
Message-ID: <4742@bu-cs.BU.EDU>
Re: all the problems with autoloading.
Hmm, seems to me that a solution would be to have a LISP hook into an
orderly virtual memory system so packages can be put (preferably
read-only and shared, re-binding would just stop pointing at the
read-only version, that happens in lisps now on such systems that
support read-only code) on page cluster (ie. 1 or more pages)
boundaries.
This should give all the advantages of auto-loading with the added
advantage of a possible auto-unloading automatically by a virtual
memory system. That is, all the features, none of the hassles,
transparent.
Seems like if we took a UNIX loader and convinced it to understand
some sort of hook (hmm, perhaps just "align each .o file" would be
enough, certainly as a start) to re-align packages* onto page or
segment boundaries it would just sort of happen.
Or am I missing something here?
[start stream-of-consciousness, sorry]
Well, replacing a package would now necessitate re-linking the LISP,
is that a fatal problem? (if everything was so neatly aligned how hard
could it be to just re-load [eg. with ld's -A flag] at the same address
and put it back into the runnable image, hmm, unless it didn't fit,
ok, well, try that and if not then re-build (or, hell, shuffle
everything down, no, that may cause problems with non-relocatable
code, ok, rebuild.) We are starting to see UNIX systems which re-build
on every boot (SYS/V), not free, but we're not talking about doing it
that often either (not on every start-up, just if a package changes.))
I assume I am going to hear that such-and-such did this in 1929, oh well.
-Barry Shein, Boston University
* Not necessarily in the CL sense of the word, I just mean a group
of functions which would be auto-loaded together.