OO File system

[Marcus Daniels]

>>>>> "CB" == Chris Bitmead uid(x22068) <Chris.Bitmead@Alcatel.com.au> writes:

MD>  Uh, uhrr..how about tweaking the GC of a favorite free Lisp
MD> implementation so that it could be used to trace out components
MD> from those symbols having an `archive' property value, and then
MD> accumulating the union of these values and storing it in a `common'
MD> symbol plist entry.  Assuming the GC happened immediately prior to
MD> image dumping, one could do different dumping operations depending
MD> on these composite/common properties (e.g. compute a key from the
MD> symbols' name and plist and then archive the key/value to a SQL
MD> server via RPC, etc..)  Maybe this sort of thing could be tightly
MD> with some sort of generational GC so as to archive incrementally?

CB> The trouble is you need the GC to be able to trace through objects
CB> that are in memory and those that are in disk. You might delete a
CB> reference to an object and that might cause a whole lot of stuff
CB> on disk to be be GCed. So the GC has to be looking at things in
CB> memory and on disk to work right.

All I'm talking about is having a way to recover the state of the
system from a database where the data in the Lisp runtime was stored
item by item with using explicit names.  If an object had an archive
tag and was to be reclaimed, it seems to me that object could simply
be deleted from the database; the job of a GC is to reclaim objects,
after all.

CB> I don't think this whole issue can be solved properly with any
CB> quick hacks. It has to built into the core of the vm and gc.

I'm not trying to solve the whole issue (hell, we don't even seem to
agree on what the issue is).  It is just that I'm not aware of a
freely available Lisp system for Unix or Win32 that does any sort of
incremental checkpointing to a documented database API.  If there is
such a program, please point me to it, because it is a feature I would
like to have.