On 02/24/2012 12:29 AM, Paul Khuong wrote:
In article <4F46518A.1070003@gmail.com>,
 Akshay Srinivasan <akshaysrinivasan@gmail.com> wrote:

    I was just fiddling around with SBCL and the garbage collection
behavior seemed rather odd to me.

* (defvar y (make-array 100000000 :element-type 'double-float
:initial-element pi))
* (setq y 0d0)
* (defvar x (make-array 100000000 :element-type 'double-float
:initial-element pi))
makes SBCL complain about stack-size limitation. Doing a (gc :full t)
before the second allocation
does not help either.  The memory usage does not come down after
allocating the big array the first time.

If your SBCL complains about *stack* size, there's something very wrong.  
I do get a heap exhaustion error.  SBCL's garbage collector is 
conservative on x86 and x86-64. This means that noise on the stack 
(typically from earlier function calls) can be considered as references 
by the GC.

It's usually not too much of an issue in practice: false references are 
often overwritten after some time.  When conservativeness does cause 
serious problems, common workarounds include explicitly calling GC at 
the right location (close to the bottom of the call stack), or abusing 
short-lived threads (each thread has its own call stack).  A less common 
but more principled approach would be to support work to rewrite the 
generational GC or make it precise.
Fair enough. Is the GC in SBCL significantly different from that in CMUCL ?
CMUCL does an amazing job clearing up the memory once the reference is destroyed.
The behavior of SBCL was in the x86-64 version though.