While compiling the lapack system from the f2cl library, SBCL drops into the low-level debugger with this error message about heap exhaustion:
Heap exhausted during garbage collection: 0 bytes available, 64 requested.
Gen Boxed Unboxed LgBox LgUnbox Pin Alloc Waste Trig WP GCs Mem-age
0 0 0 0 0 0 0 0 26843545 0 0 0.0000
1 26205 12796 0 0 9 1277771072 213696 767547401 39001 1 1.3696
2 14599 27405 117 18 88 1114241264 266569488 2000000 42139 0 0.8257
3 0 0 0 0 0 0 0 2000000 0 0 0.0000
4 0 0 0 0 0 0 0 2000000 0 0 0.0000
5 0 0 0 0 0 0 0 2000000 0 0 0.0000
6 449 220 64 47 0 24788848 770192 2000000 780 0 0.0000
7 0 0 0 0 0 0 0 2000000 0 0 0.0000
Total bytes allocated = 2416801184
Dynamic-space-size bytes = 2684354560
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
*STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 31717(tid 0x7fbb53033280):
Heap exhausted, game over.
I found postings on the maxima mailing list that recommend increasing the heap size with the --dyanamic-space-size option for sbcl, so I tried that. Even when I gave it as much memory as my RAM (~7.44 GB) it still exhausted the heap, albeit after a much longer time. I'm not quite sure where to go from here. Any ideas?
System Specs: Arch Linux and SBCL 1.4.16.
High memory consumption during compilation may happen because you are asking a high amount of debugging information. I tried compiling lapack, which failed too. It happens that in my ~/.sbclrc, I have:
(sb-ext:restrict-compiler-policy 'debug 3)
(sb-ext:restrict-compiler-policy 'safety 3)
In a fresh SBCL, the compiler policy is as follows:
* (describe-compiler-policy)
Basic qualities:
COMPILATION-SPEED = 1
DEBUG = 3
SAFETY = 3
SPACE = 1
SPEED = 1
INHIBIT-WARNINGS = 1
Dependent qualities:
SB-C::CHECK-CONSTANT-MODIFICATION = 1 -> 3 (yes)
SB-C::TYPE-CHECK = 1 -> 3 (full)
SB-C::CHECK-TAG-EXISTENCE = 1 -> 3 (yes)
SB-C::LET-CONVERSION = 1 -> 0 (off)
SB-C:ALIEN-FUNCALL-SAVES-FP-AND-PC = 1 -> 3 (yes)
SB-C:VERIFY-ARG-COUNT = 1 -> 3 (yes)
SB-C::INSERT-DEBUG-CATCH = 1 -> 3 (yes)
SB-C::RECOGNIZE-SELF-CALLS = 1 -> 0 (no)
SB-C::FLOAT-ACCURACY = 1 -> 3 (full)
SB-C:INSERT-STEP-CONDITIONS = 1 -> 3 (full)
SB-C::COMPUTE-DEBUG-FUN = 1 -> 3 (yes)
SB-C::EVAL-STORE-SOURCE-FORM = 1 -> 3 (yes)
SB-C::PRESERVE-SINGLE-USE-DEBUG-VARIABLES = 1 -> 3 (yes)
SB-C::INSERT-ARRAY-BOUNDS-CHECKS = 1 -> 3 (yes)
SB-C::STORE-XREF-DATA = 1 -> 3 (yes)
SB-C:STORE-COVERAGE-DATA = 1 -> 0 (no)
SB-C::INSTRUMENT-CONSING = 1 -> 1 (no)
SB-C::STORE-CLOSURE-DEBUG-POINTER = 1 -> 0 (no)
SB-KERNEL:ALLOW-NON-RETURNING-TAIL-CALL = 1 -> 0 (no)
In particular, the policy is restricted as follows:
* (restrict-compiler-policy)
((SAFETY . 3) (DEBUG . 3))
Those are the minimal amount of debugging and safety required, which is thus at least 3 for both. When I remove the debug restriction, with the following line:
* (restrict-compiler-policy 'debug)
((SAFETY . 3))
... then compiling the lapack system works, without changing the dynamic space size. Adding debugging information is fine when developing, and I'd encourage anyone to keep them at all time because you never know when you'll need to debug something, but in that case it is simply better to turn them off.