The LispOS Project: a position paper, part 2
Tue, 3 Jun 1997 03:30:54 -0500
| From: Scott L. Burson <email@example.com>
| From: "Dwight Hughes" <firstname.lastname@example.org>
| Date: Tue, 3 Jun 1997 02:57:27 -0500
| One of the LispM guys here (sorry, I can't remember who exactly right
| first explained a bit about this -- the details I'm still trying to
| out, but the payoff is very high efficiency usage of resources (and
| considerably better performance). One point was that the GC would
| as far as it could to all objects that it could reach *within* memory
| starting to swap - swapping only if absolutely necessary in effect;
| it can resolve it does - if not, postpone. You could, for example,
| the GC follow pointers within memory until reaching one that faults,
| 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
| the physical memory available to the GC for paging). With mine, the GC
| guaranteed to be able to make progress, just not very fast.
| One of the most important tasks of the GC is compactification. If it
| 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
| 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
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
controlled swapping to continue GC. Of course, the the size of "enough"
would control how quickly the GC would resort to swapping.