[Openmcl-devel] save-application questions.

[Gary Byers]

On Wed, 15 Feb 2006, Michael Price wrote:

> Thanks for the usual quick and thorough reply Gary. It has sparked
> another question or two.
>
> On 2/15/06, Gary Byers <gb at clozure.com> wrote:
>> :PURIFY and :IMPURIFY are (as one might imagine) inverses of each other.
>> To "purify" the image in OpenMCL is to arrange for immutable, likely
>> long-lived objects (the "code-vector" components of functions and the
>> pnames of interned symbols, currently) be copied to a read-only ("pure")
>> section of memory.  There are some memory-management benefits related
>> to this (pure/read-only memory is easier on the OS's VM system and
>> OpenMCL's GC can mostly ignore that stuff), but in some circumstances
>> it may be necessary or desirable to undo this (making everything slosh
>> around in the Big Dynamic Memory Pool.)
>
> Having never written a GC or a lisp runtime, I'm having trouble
> imagining the scenario where you want or need to undo this. Can you
> provide an example?

[I'm traveling  at the moment; the "high speed Internet access" that 
this hotel offers makes me feel old, since I'm having vivid 300 baud
modem flashbacks.  If there are more typos than usual in this reply,
that's my excuse.]

"impure" code ordinarily gets GCed, so if you do:

(defun foo (x y) (+ x y))

then redefine  FOO as

(defun foo (x y) (- x y)))

the old definition will (assuming that nothing else references it) get
GCed.  (That'd free up all of a few of dozen bytes, including maybe 2
dozen or so bytes used bythe code vector component of the function.)

If we did a SAVE-APPLICATION between those two definitions of FOO,
the code vector associated with the first definition would have
been copied to a pure, readonly memory section.  The GC doesn't
even look at such a memory section and won't bother trying to
determine whether the things in pure memory are alive or not
(that's one of the reasons for having put them there in the first
place.)  The couple of dozen bytes of machine code in the obsolete
definition would be wasted, but it's unlikely to be worth the effort
to try to reclaim them.

If we replace the scenario

a) define FOO
b) SAVE-APPLICATION
c) redefine foo,  losing a few dozen bytes

with

a) load large system takes a while to initialize itself
b) SAVE-APPLICATION
c) redefine most or all of the large system, possibly losing many MB

then one motivation for having the ability to "impurify" things might
be clearer.