The nefarious GC-OVERFLOW during FASLOAD problem

[FTP:GLS at MIT-MC (Guy L. Steele, Jr. )]

The source of this difficulty, which has been plaguing MACSYMA,
stems from a fix JONL installed for a bug to the effect that if
GC-OVERFLOW occurred, then the GC-DAEMON was not run for that GC.
The fix caused the GC-OVERFLOW to re-enter GC after the interrupt.
The problem is that if interrupts were locked out (during FASLOAD,
e.g., which must CONS with INHIBIT set for other reasons),
then several GC-OVWRFLOR interrupts could get stacked up in INTAR
before interrupts got unlocked.
I have elected to use a fix which causes GC-OVERFLOW not to
loop back into GC.  The idea is to call UINT directly from
within GC when the overflow is detected.  Since NOQUIT is set,
UINT will just stack the interrupt.  Then we simply carry on,
and run GC-DAEMON if appropriate.  (Actually, should
GC-DAEMON be run first or GC-OVERFLOW?  Under this setup
the GC-OVERFLOW gets run first, since GCRSR does a CHECKI
before running the GC-DAEMON.)
One additional advantage of this scheme is that if several spaces
get a GC-OVERFLOW, we can give interrupts for all of them,
while formerly we gave an interrupt for only one.
A possible modification of this scheme is to cause a little
extra space to be allocated even if the GCMAX is exceeded
if INHIBIT is set.  I don't think this will be necessary, however.


// 2 //