On 2012-10-22, andre maute <andre.maute at gmx.de> wrote:
> i stumbled upon the following
> which produces without the kill
> a heap exhausted error on my 2Gb machine
> under fedora 17 and sbcl 1.0.57-1.fc17
> (I can give further information if necessary)
>
> ------------------------------
> display2d : false;
> my_M(n) := ident(n);
> my_work(n) := block(
> [res:0,M],
> M : my_M(n),
> M[1,1] : 2,
> /* kill(M), */
> res : n,
> return(res)
> );
> for k : 1 thru 10 do block(
> h : my_work(3000),
> print(k,h)
> );
> ------------------------------
>
> kill fixes the heap exhausted error,
> but top shows nevertheless usage of 800 Mb resident memory
Dunno exactly what's going on, but from what I can tell, the behavior
you've observed is a consequence of the garbage collection strategy
employed by the Lisp implementation -- from what I can tell, the Lisp
implementation has not freed memory which is actually available to be
reclaimed.
I tried that example with CMUCL and Clisp. The behavior of CMUCL is
similar to what you reported for SBCL. For Clisp, the memory use
increases from about 9 Mb at start up to 90 Mb and stays there, until
:lisp (ext:gc) is issued, after which memory decreases to 9 Mb again. I
suppose Clisp's behavior is probably what we would like to see for any
Lisp implementation.
In CMUCL, I looked for symbols which are bound (and therefore presumably
not available for garbage collection) to a matrix or at least a long
list list of numbers; didn't find any.
I didn't check any other Lisp implementations, but I wouldn't be
surprised if there are a range of behaviors.
Hope this helps,
Robert Dodier