Ракудо Память / Методы сбора мусора
Я понимаю, что этот вопрос граничит с конкретными областями реализации, но на этом этапе конкретные ответы Rakudo/MoarVM мне тоже могут помочь.
Я работаю над некоторыми модулями NativeCall и задаюсь вопросом, как отлаживать утечки памяти. Некоторая память обрабатывается в библиотеке C, и у меня есть хорошая ручка там. Я знаю, что домен является моей ответственностью, и MoarVM ничего не может сделать там. Что я могу сделать в домене MoarVM? Как лучше всего проверить наличие висящих объектов, циклических ссылок и т. д.?
Есть ли способ в конце серии операций, где я думаю, что все мои объекты Perl находятся вне области, чтобы сказать "Запустить сборку мусора и рассказать мне обо всем, что осталось"?
Есть ли какой-нибудь специфичный код Rakudo/NQP/MoarVM, который я могу запустить, чтобы помочь мне? Это не для выпуска в производство, просто для тестирования / диагностики во время разработки.
Сборка мусора в MoarVM дает соблазнительный обзор, но мне не хватает информации, чтобы что-то с этим сделать.
1 ответ
Во-первых, хотя утечка памяти на стороне C не является вашей проблемой в этом случае, стоит знать, что Rakudo устанавливает perl6-valgrind-m который запускает программу под valgrind. Я использовал это несколько раз, чтобы выяснить ошибки и утечки при написании родных библиотечных привязок.
Для просмотра объектов, управляемых MoarVM, можно заставить виртуальную машину снимать снимки кучи. Они выполняются после каждого запуска GC, и выполняется дополнительный запуск GC, а в конце программы делается окончательный снимок. Для записи снимков запустите с --profile=heap, Выходной файл может быть передан в moar-ha, который может быть установлен с помощью zef install App::MoarVM::HeapAnalyzer (это реализовано в Perl 6, о чем стоит знать, если вы захотите расширить его каким-либо образом, чтобы помочь вам решить ваши проблемы).
Если у вас есть какое-либо представление о том, какие объекты могут протекать, тогда может быть полезно искать объекты этого типа с помощью find команда. Тогда есть path Команда, которая показывает, как этот объект поддерживается в живых. Также может быть полезно посмотреть количество объектов между различными снимками кучи, чтобы увидеть, что растет в использовании. К сожалению, пока нет функции сравнения снимков.
Стоит отметить, что моментальные снимки включают в себя все, что работает поверх виртуальной машины. Это означает, что в памяти будет находиться компилятор Perl 6, а также куча объектов для вещей из встроенных в язык. (Инструмент был разработан, чтобы помочь отследить управляемые утечки в компиляторе и встроенных модулях, поэтому это считается функцией.:-) Однако в будущем возможна некоторая фильтрация.)
Наконец, вы упомянули циклические ссылки. Это не проблема в Perl 6, так как GC выполняется посредством трассировки, а не подсчета ссылок.