The LispOS Project: a position paper, part 2

[Scott L. Burson]

   From: "Dwight Hughes" <dhughes@intellinet.com>
   Date: Tue, 3 Jun 1997 02:57:27 -0500

   One of the LispM guys here (sorry, I can't remember who exactly right now)
   first explained a bit about this -- the details I'm still trying to figure
   out, but the payoff is very high efficiency usage of resources (and thus
   considerably better performance). One point was that the GC would progress
   as far as it could to all objects that it could reach *within* memory before
   starting to swap - swapping only if absolutely necessary in effect; what
   it can resolve it does - if not, postpone. You could, for example, have
   the GC follow pointers within memory until reaching one that faults, then
   add the pointer to a "to do" list to tend to later.

Okay, I guess you *could* do this, but I like my proposal better (to restrict
the physical memory available to the GC for paging).  With mine, the GC is
guaranteed to be able to make progress, just not very fast.

One of the most important tasks of the GC is compactification.  If it doesn't
follow pointers to swapped-out objects, it won't be able to rearrange the
objects onto new pages the way it is designed to.  (ZetaBase in particular
goes to great lengths to get related objects close together.)

-- Scott