[Openmcl-devel] smaller images

[Gary Byers]

One thing that could be done, has some hack value, and could have some
actual benefit in some cases even today is to split the image into
"application" and "library" components.  Running one instance of a
6.5MB application doesn't put too much of a load on the VM system
of a "typical" system these days, but running hundreds of instances of
that application might.  That load could be lessened a bit if each
of those instances was able to share common code (which is immutable)
and disk requirements (at least) could be lessened if the mutable
parts were mapped copy-on-write.

MCL did this (and may still do so).  It was less flexible than it
could have been, and part of that had to do with limitations in
Classic MacOS's shared-library technology (CFM), and there was no good
way to go behind CFM's back and exercise more contol over how files
were mapped in memory.  Some parts of the problem are at least more
tractable under OSX or Linux, but there's still some lack of
flexibility and there are still a lot details to get right, and it's
not clear that there's any reason to do this unless there's a need to
run many instances of the lisp simultaneously (and it's not clear
that it helps much unless the few MB that can be shared are a
substantial part of each instance's memory requirements.)

Since what became OpenMCL was originally intended to run in embedded
systems, there was some interest in "how small can the image be made
without jumping through a lot of hoops ?", and the assumption was that
development-time things (the compiler, macro definitions, ...) 
wouldn't be needed in the execution environment.  Deciding what's
"development-time" and what's "runtime" is sometimes hard in Lisp, but
"ccl:level-1;runtime.lisp" was an attempt to have the bootstrapping
image load an alternate (smaller) set of FASL files and produce
a smaller image.  I think that it was successful (the image that
it produced was a bit over 1MB in the days when the "full" image
was ~3MB).  Even though COMPILE-CCL still dutifully tries to
compile runtime.lisp, there's been a lot of bitrot in the 7 years or
so since it was last used.

On Sun, 12 Mar 2006, Gary King wrote:

> Hi Gary,
>
> On Mar 11, 2006, at 7:32 AM, Gary Byers wrote:
>
>> If it's just some sort of general impression that "6.5MB is big", I'm
>> a little sympathetic: I occasionally get nostalgic for the days when
>> that sort of statement didn't usually have to be qualified.  (Then
>> I remember disco music and the nostalgia quickly fades ...)
>
> I was definitely thinking big in the nostalgic sense. Michael Hannemann is 
> right: 6.5 is tiny in this day and age.
>
> The original impetus for my query was because I'm thinking of making a Lisp 
> Dashboard Widget and 6.5-M is larger than your average widget.
>
> thanks,
> -- 
> Gary Warren King
> metabang.com
> http://www.metabang.com/
>
>
>