A warning for Scheme implementations that derived the Garbage Col lector from SIOD

[Carrette, George J.]

I am the author of http://people.delphi.com/gjc/siod.html and I have a
warning and a solution for Scheme implementations that derived their
original storage management architecture from the SIOD lisp implementation
or who use an older version of SIOD.
Since this is a warning about a potential class of bugs rather than a
specific bug I apologize for sending it to a bug mailing list and hope that
it can be routed to the appropriate authors for discussion.

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.

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.

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. 

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. Being forced to call a special macro at
the start of every C function call is technically correct but ugly, and
somewhat defeats the beauty of the stack-marking hack. Of course in SIOD
there is  STACK_CHECK(&elem); which is called in heavily recursive places in
order to check for stack overflow.

More abstract runtime implementation like
http://www.ccs.neu.edu/home/will/Larceny/ may have to replace directly
hand-coded C runtimes.