The feel of a LispM/List of running machines
Fri, 2 May 1997 05:38:04 -0500 (CDT)
From: email@example.com (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.