Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!van-bc!ubc-cs!alberta!arcsun.arc.ab.ca!gintera
From: gintera@arcsun.arc.ab.ca (Andrew Ginter)
Newsgroups: comp.lang.scheme
Subject: Re: what is lisp, instead?
Message-ID: <1990Aug14.202353.3998@arcsun.arc.ab.ca>
Date: 14 Aug 90 20:23:53 GMT
References: <9008132139.AA11205@mailhost.samsung.com> <9008141823.AA08641@satchmo>
Reply-To: gintera@cpsc.ucalgary.ca (Andrew Ginter)
Organization: Alberta Research Council
Lines: 27

In article <9008141823.AA08641@satchmo> rees@parc.xerox.COM writes:
>   What is one requirement for living well with C? That if you
>   have a lisp-level call to a procedure like (equal (f x) (g y)) that
>   you must be able to call it at C-level as equal(f(x),g(y));
>This is a tall order; the only solution of which I'm aware is a
>conservative GC...

There's another solution to the problem - the one I believe GNU emacs
uses.  At the top of the command loop, emacs checks that there is a
"fair" amount of memory left in the garbage collected heap (as I
recall, "fair" = no more than about 90% full).  If there's not enough
room, the collector is called.  At this point in time, there are no
pointers to the heap anywhere on the stack.  In the rare case that a
lisp command consumes all of the remaining > 10% of the heap before
returning to the top of the command loop, emacs simply allocates more
memory for the heap.

This strategy is useful only if:

(1) LISP is used as an extension language, and the system spends only
small increments of time in the interpreter before returning to the
application which called the extension language, AND

(2) there's always a little extra memory the operating system can 
supply the application in a pinch.

Andrew Ginter, 403-282-2984  gintera@cpsc.ucalgary.ca