Исчерпание кучи при компиляции системы lapack с помощью SBCL - PullRequest
Новая
       18

Исчерпание кучи при компиляции системы lapack с помощью SBCL

2 голосов
/ 28 апреля 2019

При компиляции системы lapack из библиотеки f2cl SBCL заходит в низкоуровневый отладчик с таким сообщением об ошибке исчерпания кучи: 

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.

Я нашел сообщения в списке рассылки maxima, в которых рекомендуется увеличитьразмер кучи с опцией --dyanamic-space-size для sbcl, поэтому я попробовал это.Даже когда я выделил ему столько же памяти, сколько и моей оперативной памяти (~ 7,44 ГБ), он все равно исчерпал кучу, хотя и через гораздо более длительное время.Я не совсем уверен, куда идти отсюда.Есть идеи?

Системные спецификации: Arch Linux и SBCL 1.4.16.

1 Ответ

3 голосов
/ 28 апреля 2019

Высокое потребление памяти во время компиляции может быть вызвано тем, что вы запрашиваете большое количество отладочной информации.Я попытался скомпилировать lapack, что тоже не удалось.Бывает, что в моем ~/.sbclrc у меня есть: 

(sb-ext:restrict-compiler-policy 'debug 3)
(sb-ext:restrict-compiler-policy 'safety 3)

В новом SBCL политика компилятора выглядит следующим образом: 

* (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)

В частности, политика ограничена какследует: 

* (restrict-compiler-policy)

((SAFETY . 3) (DEBUG . 3))

Это минимальный объем отладки и требуемой безопасности, который, таким образом, составляет не менее 3 для обоих.Когда я снимаю ограничение отладки со следующей строкой: 

* (restrict-compiler-policy 'debug)
((SAFETY . 3))

... тогда компиляция системы lapack работает без изменения размера динамического пространства.Добавление отладочной информации - это хорошо при разработке, и я призываю всех сохранять их постоянно, потому что вы никогда не знаете, когда вам нужно что-то отлаживать, но в этом случае просто лучше их отключить.

...