Утечка памяти в REPL SBCL

Question

Я несколько сбит с толку следующим поведением сборщика мусора SBCL в REPL. Определите две функции:

(defun test-gc ()
  (let ((x (make-array 50000000)))
    (elt x 0)))

(defun add-one (x) (+ 1 x))

Затем запустите

(add-one (test-gc))

Я ожидаю, что ничто больше не ссылается на исходный массив. Тем не менее, как сообщает (комната), память не освобождается. Я бы понял, если бы я запустил (test-gc) напрямую, то некоторые ссылки могли бы застрять где-нибудь в SLIME или в

(list * ** ***)

Но был ли это случай здесь? Спасибо, Андрей.

Обновление Некоторое время назад я подал ошибку. Это было недавно подтверждено. Увидеть: https://bugs.launchpad.net/sbcl/+bug/936304

Answer 1

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

Еще одна вещь, которая может произойти здесь, это то, что вы смотрите на использование памяти процессом Lisp. Когда память является CG, она обычно не возвращается в операционную систему. Вместо этого память просто помечается как свободная в куче и может использоваться в будущих распределениях памяти.

Answer 2

только SBCL ...

(gc :full t)

Это принудительно запустит сборку мусора для всех поколений. Я заметил, что SBCL держал тонну памяти несколько дней назад и использовал это, чтобы сбросить память до «истинного» использования.

Затем я написал макрос sure-gc, чтобы обернуть свои ненужные вычисления и эксперименты. Я вставлю его, когда вернусь домой, если я вспомню ... ничего особенного