POS

[BRIAN SPILSBURY]

HS> Well, virtual memory with an aggressive swapping algorithm - one which
HS> tries to get everything onto disk, as opposed to the more common
HS> algorithm of only moving things to disk as one runs out of ram.
HS> 
HS> Also, one which probably includes some OS hooks so that a) a swap
HS> space is dedicated to a process so that b) the process can be
HS> restarted after reboot from the swap space.

I don't have a notion of process anywhere in it. Its just persistent
virtual memory. With a couple of allocation and paging schemes.

HS> And, I guess one needs to do some sort of journalling style of swap
HS> space so that even though it'll be out of date if the lisp process is
HS> really chugging along, it'll still be self consistent.

Yep.

HS> And, the restart might be a little tricky because of TCP/IP
HS> connections, X connections, File pointers (even with transparent
HS> persistence, I'd think that file pointers in some sense or other will
HS> still be needed, for example, maybe into NFS filesystems mounted on
HS> other machines which we need to access), and all other situations
HS> where an object has an associated state which partially resides
HS> outside the system.

This is unavoidable, processes should recover from a dropped
socket, etc where possible, if not, that's the way life is.

For example an irc client should be used to having its connection die,
it should barely notice. X will be more irritable, but with design
X programs can make a new connection, shift across the resoruces it
needs, ie make up its windows and pixmaps, set up gcs, and then keep
going. This would be nice to be able to do in any case so you could
bounce applications between machines.

HS> And, as Paul Prescond keeps pointing out, unless you formalize the
HS> semantics of persistence so that the user can clean his workspace, you
HS> can easily run into applications squirreling away huge amounts of
HS> memory which is difficult for the user to track down and free.

I agree entirely, I just don't agree that that formalization belongs at
that level.

HS> And, something which I don't recall being mentioned yet, there are
HS> costs associated with keeping an object in a workspace as opposed to
HS> explicitly writing it to disk and reading it back later.  Namely,
HS> the garbage collector is going to have to keep looking at it, and
HS> possibly have to move it around, and it could be taking up valuable
HS> address space.  The gc cost I guess can be reduced through
HS> generational gc, but I don't believe it can be eliminated.

GC costs can't be eliminated, but they can be made unnoticable if you have
a garbage collection routine which runs in the background and only uses
idle time. Unnoticable until you run out of memory that is.

You can also place a portion of collection in the consing progess, ala
Incremental GC, and generations help as per usual.

I don't expect to notice much of a difference if I'm using the same program
on a machine with 7 gig of stuff, or on a machine with 100 megs.

Of course reality might trip me up here :)

Brian