Am Dienstag, 14.01.03 um 14:37 Uhr schrieb Nicolas Neuss:
> I wanted to test my new computer (1GB RAM) on some larger problems.
> Unfortunately, I can't get CMUCL to work with this large space.
>
> Trying
> (defun f () (cons () (F)))
> (F)
>
> and watching with top, I observe that CMUCL dies having allocated
> around
> 200MB.
As Raymond says, this is likely to run out of stack space first, given
that the recursion isn't tail-recursive, and cons cells are only 8
bytes in size, whereas activation records are likely to be larger (you
need at least 4 bytes for the return address, but usually also push
stuff such as frame pointers, etc. for function calls, and possibly
even a couple of caller-saved registers).
Better, as you recently said, to use iteration here ;)
A much simpler test is to do
(setq *print-array* nil)
(make-array (* 200 1024 1024) :element-type '(unsigned-byte 32)
;; Maybe initialize here, also, just to check the memory
;; really there:
:initial-element 42)
Which should alloc around 800MB...
> This happens also when I start it with
>
> cmucl -dynamic-space-size 800
>
-dynamic-space-size 1024 should make the example above work (or
anything around 20-30MB over 800, really)...
If you really needed to, you could also recompile your lisp with
increased space for the stack (would necessitate a cross-compile), but
I really think that most any program that uses more than 256 MB for the
stack is better off being rewritten to use heap instead of stack
space...
Time to apply Gerd's port of the stack-exhaustion detection code, I
guess...
Regs, Pierre.
--
Pierre R. Mai <[EMAIL PROTECTED]> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
