I am wondering about the Lisp system feature known as "incremental
worlds" (Symbolics) or "layered saved images" (Poplog). For those
who haven't heard of it, this feature enables the programmer to
load a Lisp environment, make all manner of changes (e.g., defining
new functions, building data structures), then save *only those
changes* to a file. Later, the programmer can bring up a Lisp
environment that includes that file, thereby exactly re-creating
the environment's state at the time of the save. The primary
purpose of making an incremental world instead of a complete world
(i.e., an entire saved image) is to save disk space (so that
programmers need not feel guilty about saving a large number of
worlds).
What I would like to know is, Why is this feature not more common?
I used to assume that special hardware a la Symbolics was required,
but I've just found out that Poplog Common Lisp seems to be able
to pull it off on conventional processors. But if I understand
correctly, Harlequin, Lucid, and Franz (I now consider these the
"Big Three" among Lisp implementations on Suns) don't have this
capability. Perhaps they'll consider it in the future?
Lawrence G. Mayka
AT&T Bell Laboratories
···@ihlpf.att.com
From: Jeff Dalton
Subject: Re: Incremental worlds, on conventional processors
Date:
Message-ID: <924@skye.ed.ac.uk>
In article <····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>I am wondering about the Lisp system feature known as "incremental
>worlds" (Symbolics) or "layered saved images" (Poplog). For those
>who haven't heard of it, this feature enables the programmer to
>load a Lisp environment, make all manner of changes (e.g., defining
>new functions, building data structures), then save *only those
>changes* to a file. Later, the programmer can bring up a Lisp
>environment that includes that file, thereby exactly re-creating
>the environment's state at the time of the save. [...]
>
>What I would like to know is, Why is this feature not more common?
>I used to assume that special hardware a la Symbolics was required,
>but I've just found out that Poplog Common Lisp seems to be able
>to pull it off on conventional processors.
One reason the feature is not more common is that most Lisp
implementations do not need it as much as PopLog does. In
most Lisps, I can compile a Lisp source file to get an object
(or "fasl", for "fast load") file. Since these files can be
loaded fairly quickly, and since they can perform the actions
necessary to set up a desired state, they are often an
acceptable substitute for a saved world. That is, instead
of setting up a state and then saving the world, I write a
file that sets up the state, compile it, and load it in
when needed.
Poplog does not have the ability to compile files in this way.
Instead, code is compiled as it is loaded (or typed) in, and to
save any object code it's necessary to save a world.
In some cases, saved worlds are better; in other cases, though,
it's better to have compiled files. For example, it there tend
to be fewer ordering constraints when loading several compiled files
than when trying to restore several saved worlds.
Of course, some Lisps have both capabilities.
-- Jeff
From: Richard O'Keefe
Subject: Re: Incremental worlds, on conventional processors
Date:
Message-ID: <2175@munnari.oz.au>
In article <····@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>I am wondering about the Lisp system feature known as "incremental
>worlds" (Symbolics) or "layered saved images" (Poplog).
>What I would like to know is, Why is this feature not more common?
>I used to assume that special hardware a la Symbolics was required,
The problem isn't a hardware problem. It's a software problem.
Basically, what do you do when your ``world'' contains areas of memory
which are shared with other processes? Quintus Prolog provides the
DEC-10 Prolog 'save(WorldImage)' and 'restore(WorldImage)' commands;
this used to work just fine in UNIX, and then a customer complained
about problems when he had a frame buffer mapped into the address
space we thought we were managing. Quintus worked out a way around
that, but in some operating systems (Aegis, VMS, now SunOS 4, others)
it gets weird: if you have a file mapped into your address space,
should the saved state include a *copy* of the file or a *reference*
to the file? If the latter, what should you do if the file isn't
there when the saved state is restored? (This problem hit Quintus on
the Apollos.) If the former, remember that files can get *very* big.
(Also remember that the operating system may map files into your
address space without telling you.)
From: Barry Margolin
Subject: Re: Incremental worlds, on conventional processors
Date:
Message-ID: <30019@news.Think.COM>
In article <···@skye.ed.ac.uk> ····@aiai.uucp (Jeff Dalton) writes:
>That is, instead
>of setting up a state and then saving the world, I write a
>file that sets up the state, compile it, and load it in
>when needed.
This sounds like you're arguing against saved worlds in general, not
just incremental worlds. I don't know of any professional-quality
Lisps that don't provide saved worlds. Would you really prefer to
load several hundred compiled files rather than start up a saved
world? It takes us an hour to load the basic Connection Machine
software into Lucid on a Sun-4; we'd be dead without saved worlds, if
everyone had to reload the software every time they started up Lisp.
>In some cases, saved worlds are better; in other cases, though,
>it's better to have compiled files. For example, it there tend
>to be fewer ordering constraints when loading several compiled files
>than when trying to restore several saved worlds.
What kinds of ordering constraints are there with incremental worlds?
The routine for loading incremental worlds should handle this
automatically.
Compiled files, on the other hand, often have ordering constraints.
You have to load the file that defines a package before loading files
that reference the package. And if a file contains any top-level
function calls you have to load the files that define the functions
before loading it.
Barry Margolin
Thinking Machines Corp.
From: Jeff Dalton
Subject: Re: Incremental worlds, on conventional processors
Date:
Message-ID: <937@skye.ed.ac.uk>
In article <·····@news.Think.COM> ······@kulla.UUCP (Barry Margolin) writes:
>In article <···@skye.ed.ac.uk> ····@aiai.uucp (Jeff Dalton) writes:
>>That is, instead of setting up a state and then saving the world, I
>>write a file that sets up the state, compile it, and load it in
>>when needed.
>This sounds like you're arguing against saved worlds in general, not
>just incremental worlds.
Sorry. I didn't intend to argue against either, just to point out
that loading compiled files was sometimes a reasonable alternative.
Then, because Poplog can't compile files, it's more important that
it provide incremental worlds. I would not consider saved worlds
of any sort a point against any Lisp that provided them.
>I don't know of any professional-quality Lisps that don't provide
>saved worlds.
Neither do I. Moreover, I wish more of them provided incremental
worlds so that the resulting files would be smaller.