>>>>> "Mark" == Mark Saaltink <[EMAIL PROTECTED]> writes:
Mark> Dear CMUCL developers,
[snip]
Mark> CMU Common Lisp 19a-pre2, running on basement
Mark> With core: /opt/cmucl-19a-pre2/lib/cmucl/lib/lisp.core
Mark> Dumped on: Sat, 2004-06-05 01:28:16-04:00 on lorien
Mark> See <http://www.cons.org/cmucl/> for support information.
Mark> Loaded subsystems:
Mark> Python 1.1, target Intel x86
Mark> CLOS based on Gerd's PCL 2004/04/14 03:32:47
Mark> * (dotimes (x 20) (loop for x below 1000 collect (make-array x)) (room))
[snip]
Mark> ; [GC threshold exceeded with 285,090,296 bytes in use. Commencing GC.]
Mark> ; [GC completed with 8,541,904 bytes retained and 276,548,392 bytes freed.]
Mark> ; [GC will next occur when at least 20,541,904 bytes are in use.]
Mark> Breakdown for dynamic space:
Mark> 69,089,416 bytes for 8,636,177 sap objects.
Mark> 69,025,136 bytes for 8,628,139 bignum objects.
Mark> 8,375,688 bytes for 4,124 simple-vector-type objects.
Mark> 208,000 bytes for 18,089 other objects.
Mark> 146,698,240 bytes for 17,286,529 dynamic objects (space total.)
Mark> Dynamic Space Usage: 10,647,856 bytes (out of 512 MB).
Mark> Read-Only Space Usage: 20,024,704 bytes (out of 256 MB).
Mark> Static Space Usage: 2,908,608 bytes (out of 256 MB).
Mark> Control Stack Usage: 868 bytes (out of 128 MB).
Mark> Binding Stack Usage: 96 bytes (out of 128 MB).
Mark> The current dynamic space is 0.
Mark> Garbage collection is currently enabled.
Mark> *A2 gc_alloc_new_region failed, nbytes=8.
Mark> CMUCL has run out of dynamic heap space (512 MB).
This same test on Solaris with gencgc doesn't have an issue. It runs
to completion without problems and without sucking up so much memory.
It definitely doesn't have millions of sap objects hanging around.
And it's not Fedora2, because this also crashes on my x86 Suse 9
system.
Mark> You can control heap size with the -dynamic-space-size commandline option.
Mark> Imminent dynamic space overflow has occurred: Only a small amount of dynamic
Mark> space is available now. Please note that you will be returned to the
Top-Level
Mark> without warning if you run out of space while debugging.
Mark> Heap (dynamic space) overflow
Mark> [Condition of type KERNEL:HEAP-OVERFLOW]
Mark> Restarts:
Mark> 0: [ABORT] Return to Top-Level.
Mark> Debug (type H for help)
Mark> (KERNEL:DYNAMIC-SPACE-OVERFLOW-WARNING-HIT)
Mark> Source: Error finding source:
Mark> Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer
exists:
Mark> target:code/interr.lisp.
Mark> 0] a
[snip]
Mark> This last message repeats until I kill the process. A smaller loop,
Mark> (dotimes (x 10) (loop for x below 100 collect (make-array x)) (room)),
Mark> gives a similar result, except it is abortable to the toplevel. Once
Mark> there, running (room) exhausts memory.
Heap overflow checking isn't so good and isn't always recoverable.
But at least it can sometimes recover, instead of always dying.
Mark> In my larger system I was running, removing calls to ROOM eliminated
Mark> the crashes I was experiencing, and I was able to complete a full 12
Mark> cpu minutes of regression tests without any failures, and with lots of
Mark> gc activity.
ROOM conses a lot. That might cause the problems too. Using (room
nil) instead of (room) allows your test to finish, so (room) must be
causing things to survive that shouldn't.
Ray
