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

Question

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

Answer 1

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

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

Для программ, работающих на нескольких ядрах, имеющих действительно параллельный сборник, было бы неплохо, но вы также можете получить приличную выгоду, выполнив кучу местных сбор мусора. Идея состоит в том, что данные, которые не разделяются между несколькими процессорами, могут собираться только владельцем ЦП. Обычно это относится к краткосрочным данным. Саймонс проделал некоторые недавние работы в этой области. См. Их статью "Multicore Garbage Collection with Local Heaps" (PDF). В этой статье также показаны некоторые способы использования неизменяемости способом, аналогичным тому, что вы предлагаете.

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

Answer 2

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

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

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

Начните с хорошей книги, такой как the GC handbook (Ричард Джонс, Антони Хоскинг, Элиот Мосс). Или, по крайней мере, wikipedia Garbage Collection страница.

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

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