The LispOS Project: a position paper, part 2

[Dwight Hughes]

| From: Scott L. Burson <gyro@zeta-soft.com>
| 
|    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.)

You could do both -- do everything you can in memory, compactifying as is
doable -- if the freed space is "enough" (however you want to define
"enough")
stop GC, start process, repeat as necessary, until GC can free less than
"enough" memory (limit the GC to one or two passes, for example), then
begin
controlled swapping to continue GC. Of course, the the size of "enough"
would control how quickly the GC would resort to swapping.

-- Dwight