[no subject]

[Rob_MacLachlan@LISP-PMAX2.SLISP.CS.CMU.EDU]

       Another major problem with compilation to C is garbage collection.
       Without a lot of compiler hooks, you are pretty much forced to use a
       conservative garbage collector.

   Other people report good results with this technique.  Why should the
   complexity of CL increase the likelihood that a fixnum will be the
   address of Lisp data?

It's not the complexity of CL itself, but the complexity and implementation
strategy of CMU CL.  I am suspicious that much of the satisfactory
experience with conservative GC is in simple applications in which the
process doesn't live a lot longer than many of the objects.

In a lispm-like environment like CMU CL, we expect processes to run for
days without memory leakage.  The slight degree of conservatism that we
already have (GC doesn't know which stack slots are live) has already
caused problems with compiler performance.

Since a spuriously retained pointer can retain megabytes of data structure,
retaining only a few stray pointers can cause the heap to become so bloated
that GC grinds to a halt.  We have partly solved this problem by GC'ing
when the stack is short, but this solution isn't totally satisfactory.

  Rob