Сборка мусора в Haskell и параллельные вычисления

Question

Большинство языков, использующих сборщики мусора (возможно, все они), имеют одну главную проблему, связанную с параллельными вычислениями: сборщик мусора должен останавливать все запущенные потоки, чтобы удалить неиспользуемые объекты. На Хаскеле тоже есть сборщик мусора. Но, благодаря чистоте, Haskell гарантирует, что никакие вычисления не изменят исходные данные, вместо этого он создает копию, а затем вносит изменения. Я полагаю, что таким образом GC не должен останавливать все потоки, чтобы выполнить свою работу. Мне просто любопытно: у Haskell такая же проблема со сборкой мусора или нет?

Answer 1

Сборщик мусора GHC параллельный , но не параллельный .Это означает, что он может использовать все потоки для выполнения сборки мусора, но для этого он должен остановить все потоки.Одновременную сборку мусора реализовать гораздо сложнее (и, как правило, это приводит к большим потерям производительности).

Несколько иронично, что Haskell действительно использует множество изменяемых объектов, а именно thunks (выражения без оценки).Изменяемые объекты не могут свободно дублироваться (и даже для неизменяемых объектов следует проверять слишком много дублирования).

Для программ, работающих на нескольких ядрах, с действительно параллельным сборщиком было бы неплохо, но вы также можете получить приличные преимуществавыполнив heap-local сборщик мусора.Идея состоит в том, что данные, которые не используются несколькими ЦП, могут быть собраны только самим ЦП.Обычно это относится к недолговечным данным.Саймонс сделал некоторые недавние работы в этой области.См. Их статью «Многоядерный сборщик мусора с локальными кучами» (PDF) .В этой статье также показано, как вы можете использовать неизменность таким же образом, как вы предлагаете.

Редактировать: Я забыл упомянуть, что Эрланг в основном делает именно то, что вы предлагаете.Каждый процесс Erlang имеет свою собственную кучу, и отправка сообщения копирует данные из одного процесса в другой.По этой причине каждый процесс Erlang может делать свой собственный GC независимо от всех других процессов.(Недостатком является то, что Erlang не дает вам параллелизма совместно используемой памяти.)

Answer 2

Реализации Seval GC могут работать параллельно, не «останавливая мир», как вы предлагаете (я думаю, что последняя Oracle JVM не останавливает мир и, например, является многопоточной; и большинство JVM не «остановят -Мировой ").

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

В ГХ много литературы, и еще много научных работ по параллельному сбору мусора.

Начните с хорошей книги, такой как Справочник ГК (Ричард Джонс, Энтони Хоскинг, Элиот Мосс). Или хотя бы википедия Сборка мусора стр.

Чисто функциональные языки, такие как Haskell, в значительной степени зависят от очень производительного GC. Другие языки имеют другие ограничения (например, барьеры записи имеют меньшее значение для Haskell, чем для Java, но программы на Haskell, вероятно, выделяют больше, чем Java).

Для параллельного GC, дьявол очень в деталях.