The LispOS Project: a position paper, part 2

[Scott L. Burson]

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

   On Tue, 3 Jun 1997, Scott L. Burson wrote:

   [snip]
   > 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

   I'm confused. You want to force the OS to trow away a page from the
   current GC generation (I'm assuming you are talking about a generational
   GC here, or else I can't see any difference between GC controled memory
   and the application) if it needs more memory? In the worst case this would
   force the program to run at the speed of the disc...

   I would rather force out the _oldest_ generation first (both oldest in
   use, and not recently referenced). For example: when I'm compiling in
   CMUCL, hemlock can be swapped out. I don't want it for a while, so I won't
   miss it. I don't want to reduce my image, just because you want to force
   Lisp to keep it all in memory...

   In fact, except for _during_ GC I can't see how "last recently used" is
   bad for performance... (Except some details like meta information etc that
   shouldn't be swapped out etc) I would like some control about what page
   gets thrown out (mostly _during_ GC), and dirty page info direct from the
   OS would be fine, etc. A lot of the controls are allready there...

I agree: you're confused :-)

First off, I *am* talking about *during* GC.  The only time the GC could cause
a page fault is while it is running.

Secondly, the age of a generation has nothing, in general, to do with how
recently the pages of that generation have been referenced.  It has only to do
with how many GC cycles the objects in the generation have survived.

And thirdly, which I should have explained, I am really talking here about
background collections of older generations.  We would like to be able to do
these, as I say, without having them chew up all our real memory.  Young
generations tend to be small enough that this isn't a problem anyway.

-- Scott