Re: A warning for Scheme implementations that derived the Garbage Collector from SIOD

[Aubrey Jaffer]

 | From: "Carrette, George J." <address@hidden>
 | Date: Tue, 12 Jun 2001 09:33:46 -0400
 | 
 | The problem is that the implicit assumption about machine stack
 | organization used in the gc_mark_and_sweep were never universally
 | true, and could have failed on strange architectures that were highly
 | unlikely to be encountered.

There are many causes for program degradation with time, even when
obsolescence is not intentional.  Each new release of Linux breaks
software which ran fine in previous releases (eg VRwave).

And the decay is not limited to programs.  LaTeX circa March 2000 no
longer correctly processes R3RS and R4RS (1991).  New releases of Emacs
require quality time with one's customization files.

Non-trivial programs seem to die within two years after their
maintenance ceases.  Documents are longer-lived but still mortal.

 | But now these "highly unlikely" situations of non-linear C call-stack
 | management are becoming more likely, and the implementation
 | assumptions are soon to hit-the-fan in a hard way as the next
 | generation of 64-bit processors become mainstream.
 | 
 | I've had problems with some SPARC and AIX situations.

SCM has supported both of these architectures for years.  The problem on
the SPARC (which manifests as bloated memory only when using many saved
continuations) is not that of finding all references, but of
pre-clearing them.  I am sure some SPARC maven at Sun could tell us how
to clear the register windows; anyone know one?

 | Obviously there are other codebases that will have similar
 | problems. The classic Sun JAVA VM implementation depended on raw
 | stack marking, as well as the more general (and earlier) work of
 | Boehm-Demers-Weiser conservative garbage.

This should be good news -- Sun is aware of stack marking and has
motivation to keep it working in its processors.

 | SOLUTION: Unfortunately, I don't have a solution that provides the
 | same straightforward, unencumbered use of C programming style for
 | Lisp data structures that we have depended on.

Trying to create (non-trivial) immortal C code is futile because C is a
moving target.  For example, POSIX libc changes mandate that use of
functions like signal(), sigprocmask(), and siginterrupt() all be
conditionalized to maintain portability.