The LispOS Project: a position paper, part 2

[Scott L. Burson]

   From: "Peter.VanEynde" <s950045@uia.ua.ac.be>
   Date: Tue, 3 Jun 1997 08:12:20 +0200 (MET DST)

   On Tue, 3 Jun 1997, Dwight Hughes wrote:

   > Some general comments:
   > 
   > The use of a Mach-type kernel would certainly be better for
   > our purposes than using a monolithic kernel based Un*x --
   > that much less to wade thru. What is the status of MkLinux?

   Sorry? Why should a Mach-type kernel be better?

It was my impression that Mach had better facilities for allowing processes to
do their own thing with page faults.  This seems likely to be useful in the
implementation of persistence.

But I can't give you exact details of what feature Mach has that Linux lacks
that would be so useful.  This should be looked into.

   > Is it reasonably stable yet? How about on x86 hardware?

   Seems reasonably stable. It works on x86, PowerPC and recently HP-PA
   machines. IRC OSF selected it as the "bare minimum" server they will use
   in all future ports of Mach...

Oh, okay, I didn't look on the right Web page.

   > I would also agree that as a hardware platform for a LispOS,
   > the PowerPC would be much nicer to work with than the x86 
   ...

   Problem: there is no native code generator for the PowerPC in CMUCL. But
   there is for the HP-PA, the Sparc and the Alpha (all now supported by
   Linux). 

Well, my proposal was to do code generation via Orbit (which doesn't have a
PowerPC codegen either).

For my research purposes I will need a Lisp with firstclass continuations, so
simply porting CMUCL won't do it for me.

   > 1) the tight integration of GC and virtual memory (both
   > hardware and software aspects), giving the ability to allow
   > each to control the other tightly and take maximum advantage
   > of resources (for example, being able to constrain GC to
   > only deal with in-memory pages whenever desired);

   I was thinking of this. It _can_ be done with a minimal kernel module and
   mmap. But I've got philosophical problems: if you want to collect the
   garbage in memory, you need to know what memory is referenced by the
   swapped out memory. And how can you know that without swapping it in, or
   keeping an expensive "pointers from outer space" list? But I know only a
   little about GC, so can someone enlighten me?

Well, you can't really "constrain the GC to deal only with in-memory pages",
but you *can* constrain it to a specified portion of real memory, so that when
it takes a page fault, the page selected for replacement is one that was
brought into memory by a previous GC page fault.  This makes the GC thrash
harder, but keeps it from evicting the rest of your application from memory.
The Lisp Machine needed such a feature badly, but for some reason, to my
knowledge, never got it.

-- Scott