Каковы возможные способы сбора мусора в параллельных системах?

Question

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

Существуют ли конкретные методы для сбора мусора объектов вмногопоточные системы?Где я могу найти информацию об их архитектуре и реализации?

Answer 1

Параллельная сборка мусора на самом деле намного сложнее понять правильно.Однако было проведено исследование алгоритмов одновременной сборки мусора.

Mark & ​​Sweep: http://doc.cat -v.org / inferno / concurrent_gc /

Mark & ​​Sweep (Предупреждение в формате PDF): http://www.win.tue.nl/~jfg/articles/CSR-04-31.pdf

Копирование с генерацией: https://labs.oracle.com/techrep/2000/abstract-88.html

Копирование с генерацией: http://chaoticjava.com/posts/parallel-and-concurrent-garbage-collectors/

Сложность заключается в синхронизации потоков, поэтому кучи нетне в непоследовательном (недействительном) состоянии.

Answer 2

Существуют ли специальные методы для сбора мусора объектов в многопоточных системах?Где я могу найти информацию об их архитектуре и реализации?

Существует два основных решения:

1. Запретить мутации и использовать ссылочную прозрачность в результирующей однонаправленной кучепутем глубокого копирования значений, когда они передаются из одного потока в другой.Тогда используйте не одновременный сбор.Эрланг делает это.

2. Используйте одновременный сборщик мусора.См. Справочник по сборке мусора глава 15, Параллельная сборка мусора, для получения подробной информации..NET и JVM делают это.Вам понадобится барьер записи (Dijkstra, Steele или Yuasa) для записи мутаций топологии кучи во время работы сборщика.

Параллельные сборщики мусора варьируются от полного параллелизма (нетпаузы) к большей части одновременных (некоторые короткие паузы остановки мира, обычно чтобы получить самосогласованный снимок глобальных корней).Полный параллелизм является дорогостоящим с точки зрения пропускной способности, потому что информирование GC о постоянно меняющейся топологии кучи требует детальной синхронизации.Грубая синхронизация возможна с такими сборщиками, как красивый Очень параллельный сборщик мусора (VCGC).FWIW, я написал статью о реализации VCGC в F # для F # .NET Journal.

Answer 3

Может быть, я просто не очень хорошо понимаю это ... Но какое отношение параллелизм имеет к тому, сколько ссылок на объект живы?У него либо есть живые ссылки, либо нет;несколько потоков не влияют на это.

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

Кроме того, почему бы просто не запрограммировать ваш интерпретатор поверх виртуальной машины, которая уже делает все это?Как сделали JRuby (Java VM) или IronPython (.NET).