The feel of a LispM/List of running machines

[David Gadbois]

   From: marcus@cathcart.sysc.pdx.edu (Marcus G. Daniels)
   Date: 01 May 1997 20:23:06 -0700

   Hrmm.  This seems to raise another issue: even with threads for
   CMUCL, even with layering LispOS on top of a Unix system or
   microkernel, an overriding goal here is to get as much as possible
   in to one Lisp address space, right?  If we are pointing all these
   system services into one Lisp process, doesn't this mean that we'll
   run in to sluggishness without some kind of non-blocking GC?

Sure, so we'd need to have an incremental GC.  That implies a
read-barrier, probably implemented via page-level protection bits.
The nice thing about a single address space and no kernel/user
distinction is that such tricks are reasonable to do:  You don't have
to do zillions of context switches and argument validations in order
to change page protections and take read traps.

I have been hacking garbage collectors a lot lately, and I'm just
drooling over the possibilities for the things you can do when you
have real system support for them:  cheap access to VM services,
getting to define atomicity, precise pointer/non-pointer distinctions,
and so forth.

   Perhaps we'd be better off coming up with a good-performance way to
   share Lisp objects across multiple Lisp processes?

That would be nice to have anyway.  Imagine a generic distributed
object system analogous to the Symbolics generic file system interface
folks have been discussing.  No sweat fretting over which camp (CORBA,
XCOM, etc) to join:  We'll do 'em all, and not care.

--David Gadbois