Garbage Collector Troubles

[bill@cambridge.apple.com (Bill St. Clair)]

At  8:21 AM 7/19/93 +0000, Ranson wrote:
>The graying of windows during a GC is a feature. It means the windows need
>updating, but the Lisp code to update them cannot run during a GC...
>
>The infinite GC symptom means you are running with memory almost full. You code
>fills the free memory almost instantly, provoking a GC, and so on. Increasing
>the partition size for MCL may help a lot. Of course, if you keep loading data
>that cannot be GC-ed, you'll run out of memory anyway.

Daniel is correct. I have a little more to say about this.

If one or more of your VIEW-DRAW-CONTENTS methods conses, and you are
very nearly out of memory, you can get into an infinite GC loop of the
type you describe. There are a few possible fixes for this.

1) Eliminate the consing in your VIEW-DRAW-CONTENTS methods.
   This may be difficult. If your window includes a TABLE-DIALOG-ITEM
   or SEQUENCE-DIALOG-ITEM, it will be well nigh impossible since MCL's
   VIEW-DRAW-CONTENTS method for TABLE-DIALOG-ITEM conses.

2) As Daniel recommended, increase MCL's partition size (using the Finder's
   "Get Info" command).

3) Stop the GC from calling #_WaitNextEvent. This will prevent it
   from getting update events that it can handle only by graying out
   the update region and setting a bit to make all the windows be
   redrawn when GC is done. You can do this with the following code:
   (set-gc-event-check-enabled-p nil).

We added the GC event polling feature so that if MCL garbage collects
while it is in the background, your Word processor or mail program will
still be useable. The graying out of update regions and the possibility
of a GC loop were unfortunate side affects of that feature. Hence, we
provided a way to disable it.