Ответ 1
Справочный документ для алгоритма: One Pass Real-Time Generation Mark-Sweep Garbage Collection (1995) от Joe Armstrong и Robert Virding в 1995 году (на CiteSeerX)
Я хочу узнать технические подробности о сборке мусора и управлении памятью в Erlang.
Но я не могу найти его в Erlang.org и его документах.
Некоторые статьи в Интернете - это только общие разговоры, не касаясь деталей, например, какой алгоритм сбора мусора используется, что такое служебные накладные расходы, распределение памяти также похоже на кучу в C?
Кто-нибудь может рекомендовать лучше изучить документы?
спасибо
Справочный документ для алгоритма: One Pass Real-Time Generation Mark-Sweep Garbage Collection (1995) от Joe Armstrong и Robert Virding в 1995 году (на CiteSeerX)
У Erlang есть несколько свойств, которые делают GC фактически довольно легким.
1 - Каждая переменная неизменна, поэтому переменная никогда не может указывать на значение, которое было создано после нее.
2 - Значения копируются между процессами Erlang, поэтому память, упоминаемая в процессе, почти всегда полностью изолирована.
Оба эти (особенно последние) значительно ограничивают количество кучи, которое GC должна сканировать во время сбора.
В Erlang используется копирующий GC. Во время GC процесс останавливается, а живые указатели копируются из пространства из пространства в космос. Я забываю точные проценты, но куча будет увеличена, если во время сбора можно будет собрать только 25% кучи, и она будет уменьшена, если можно собрать 75% кучи процесса. Коллекция запускается, когда куча процесса заполняется.
Единственное исключение - это когда дело доходит до больших значений, которые отправляются другому процессу. Они будут скопированы в общее пространство и будут подсчитаны. Когда собрана ссылка на общий объект, счетчик уменьшается, когда этот счет равен 0, объект освобождается. Не предпринимаются попытки обработать фрагментацию в общей куче.
Одним из интересных следствий этого является то, что для общего объекта размер общего объекта не способствует расчетному размеру кучи процесса, а только размер ссылки. Это означает, что если у вас много больших общих объектов, ваша виртуальная машина может исчерпать память до запуска GC.
Большинство, если это взято из разговора, которое Йеспер Вильгельмссон дал в EUC2012.
Чтобы классифицировать вещи, давайте определим макет памяти, а затем поговорим о том, как работает GC.
В Erlang каждый поток выполнения называется процессом. Каждый процесс имеет свою собственную память, а макет памяти состоит из трех частей: Блок управления технологическими процессами, Стек и Куча.
PCB: Блок управления технологическими процессами содержит информацию, такую как идентификатор процесса (PID), текущий статус (работающий, ожидающий), его зарегистрированное имя и другая такая информация.
Стек: Это растущая область памяти, которая поддерживает входящие и исходящие параметры, возвращает адреса, локальные переменные и временные пространства для оценки выражений.
Куча:. Это растущая область памяти, которая содержит сообщения почтового ящика процесса и сложные термины. Бинарные термины, размер которых превышает 64 байта, НЕ хранятся в частной куче процесса. Они хранятся в большой общей куче, доступной для всех процессов.
В настоящее время Erlang использует сборку мусора Generational, которая выполняется внутри каждой частной очереди процесса Erlang независимо, а также сборка мусора Reference Counting происходит для глобальной общей кучи.
Частная куча GC: Это поколение, поэтому разделяет кучу на два сегмента: молодые и старые поколения. Также есть две стратегии для сбора; Генерация (Малая) и Fullsweep (Major). Генерал GC просто собирает молодую кучу, но fullsweep собирает как молодую, так и старую кучу.
Общая куча GC: Это подсчет ссылок. Каждый объект в общей куче (Refc) имеет счетчик ссылок на него, хранящийся другими объектами (ProcBin), которые хранятся внутри частной кучи процессов Erlang. Если счетчик ссылок объекта достигает нуля, объект становится недоступным и будет уничтожен.
Чтобы получить более подробную информацию и рекомендации по производительности, просто взгляните на мою статью, которая является источником ответа: Сведения о сборке мусора Erlang и почему это имеет значение
Я не знаю вашего фона, но кроме бумаги, уже упомянутой jj1bdx, вы также можете дать тезис Джеспера Вильгельмсона.
BTW, если вы хотите контролировать использование памяти в Erlang, чтобы сравнить его, например. С++ вы можете проверить:
Надеюсь, это поможет!