Garbage (collection, that is...)

Phil Howard KA9WGN phil at ux1.cso.uiuc.edu
Tue May 7 08:50:38 AEST 1991


leipold at eplrx7.uucp (Walt Leipold) writes:

>The stack is gc'd by saving the address of a main-program automatic
>variable, and scanning between there and the address of a current auto
>variable for anything that looks like a Scheme pointer.  Registers are
>gc'd by calling setjmp() and then examining the register values saved in
>the jmp_buf structure.  As a Portability Paranoid(TM), I find this
>frightening, since (for instance) I don't think that C is even required
>to use a stack to store activation records.

Or at least not a stack implemented as a contiguous array.

The C on IBM 370 seems to work just fine using the saveareas that said
architecture commonly uses.  Think of saveareas as a stack whose activation
records are chained together doubly-linked.  They can be allocated, but
don't have to be.

>I'm pretty sure that gc'ing off the C stack is non-portable practice. Is
>it *good* practice?  In how many current implementations are C activation
>records *not* allocated contiguously on a stack?  Should I look elsewhere
>for a Scheme interpreter?  (Or am I worrying too much?)

What about systems that can detect a stack overflow and recover by creating
an extension that is non-contiguous (with all the appropriate stuff put in
to make sure you get back when existing).
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil at ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



More information about the Comp.lang.c mailing list