Compiler/GC problem

[Scott_Fahlman@SEF-PMAX.SLISP.CS.CMU.EDU]

Enclosed is an excerpt from one of the surveys.  I know this compiler/GC
bug (or one like it) has come by before.  Do we have a fix for this guy, or
any good advice?  IF this kind of problem doesn't go away when the
generational GC arrives, we're going to have to do some serious tuning.

-- Scott
===========================================================================
From: Timothy Winkler <winkler@csl.sri.com>

I had serious problems with compiling the whole OBJ3 system.
My guess was that some compiler analysis routines were going
off the deep end.  The primary sympton was that the compilation
would grind away, and the running instance of Lisp would grow until
pathological swapping would start.  This is, no doubt, related to the
way that I have handled the compilation of OBJ3, by first loading
all the code and then compiling everything.  I changed things
so that only required definitions are loaded (defmacros, defstructs,
etc.), and then compiling.  This allowed me to build OBJ3.
I also used the following little bit of code to detect that
pathological situation
    (defun check-gc (n)
      (lisp::default-gc-notify-before n)
      (when (< 30000000 n)
	(break "Compile fails with pathological GC"))
      nil)
    (setq ext:*gc-notify-before* 'check-gc)
There seems to be some issue here about compile-time treatment
that it might be worth while documenting.  (Definitions, e.g. defmacro,
need to be treated separately from uses.)

I found it necessary to set "(lisp::set-auto-gc-trigger 2000000)",
in the start-up of a save-d image, which I think is a bug (not sure).