Почему GC SBCL может не освобождать память?

Written on 2025-01-18

Последнее время я работаю над новой версией фреймфорка для создания Telegram ботов. Этот фреймворк использует библиотеку реализующую акторы. И нем обнаружился досадный баг, который я намеревался исправить. Однако в процессе исправления оказалось, что оно может повлиять на производительность. Хорошо что у автора отыскался benchmark с помощью которого можно проверить скорость работы актора.

К моему удивлению этому бенчмарку не хватало 4G памяти для хоть сколько-нибудь длительной работы. Более того, если бенчмарк запустить ненадолго, то оказывалось, что после его работы процесс "толстел" на 2.5G и не отпускал эту память до тех пор, пока не сделаешь вручную (sb-ext:gc :full t).

Это поведение показалось крайне странным. Как вообще можно использовать это язык в production, если он не отпускает память!?

Так я оказался втянут в исследование того, почему garbage collector SBCL не очищает кучу мусора оставшуюся после теста.

Прошло три дня.

После некоторых исследований у меня появилась гипотеза, почему GC не очищает память.

Дело в том, что в бенчмарке N потоков генерят сообщения к одному актору. Если актор не успевает разгребать сообщения, то те накапливаются в очереди. Тест заканчивается, когда все сообщения в очереди обработаны.

Когда в очереди много сообщений и срабатывает GC, то он видит, что на эти сообщения есть ссылки, и не может их подчистить, а потому перекладывает эти объекты в более старшее поколение. И чем дольше разгребается очередь в процессе генерации объектов, тем больше таких объектов оказывается в старших поколениях garbage collector.

Когда тест заканчивается, то ссылок на сообщения уже нет, но из-за того, что GC поместил их в старшие поколения, при регулярных запусках он до этих объектов не добирается и они так и остаются висеть в памяти. А вот (gc :full t) их подбирает и подчищает.

Как я это понял? Хотелось бы ответить: "Очень просто!", но нет 🙁

Сначала я решил поисследовать природу объектов, остающихся висеть в памяти после бенчмарка и написал вот такую функциюЖ

(defun get-random-dynamic-object ()
  (let ((count 0))
    (sb-vm:map-allocated-objects (lambda (obj type size)
                                   (declare (ignore obj type size))
                                   (incf count))
                                 :dynamic)
    (let ((random-idx (random count))
          (found-obj nil)
          (current-idx 0))
      (sb-vm:map-allocated-objects (lambda (obj type size)
                                     (declare (ignore type size))
                                     (when (= current-idx random-idx)
                                       (setf found-obj
                                             (trivial-garbage:make-weak-pointer obj)))
                                     (incf current-idx))
                                   :dynamic)
      (values found-obj
              random-idx
              count))))

она достает из памяти случайны объект и возвращает weak указатель на него. Почему weak указатель? Чтобы не возникло лишней ссылки на объект.

Выяснилось, что значительная часть объектов, это сообщения из очереди актора:

#<weak pointer: (#<ACTOR path: /user/actor-365, cell: #<ACTOR actor-365, running: NIL, state: NIL, message-box: #<MESSAGE-BOX/BT mesgb-366, processed messages: 8000001, max-queue-size: 0, queue: #<QUEUE-UNBOUNDED {70050E0113}>>>>
                    NIL NIL)>

Далее я попытался выяснить а не держит ли кто ссылки на эти объекты. Для этого в SBCL есть функция поиска корней:

• ← Previous
• Next →