Сборщики мусора для многоядерных llvm?

Question

Я довольно давно смотрю на LLVM как на новый бэкэнд для языка, который я сейчас внедряю. Кажется, у него хорошая производительность, довольно высокоуровневые API-интерфейсы, достаточно низкоуровневой поддержки для оптимизации экзотических оптимизаций. Кроме того, и хотя я сам не проверял это, Apple, похоже, успешно продемонстрировала использование LLVM для многоядерных программ со сборкой мусора.

Пока все хорошо. Поскольку я интересуюсь как сборкой мусора, так и многоядерностью, следующим шагом будет выбор сборщика мусора с поддержкой многоядерности LLVM. Что подводит меня к вопросу: что доступно? Я знаю о работе Джона Харропа по HLVM, но это все.

Обратите внимание, что мне нужен кроссплатформенный, поэтому GC от Apple, вероятно, не то, что я ищу (если только нет кроссплатформенной версии). Также обратите внимание, что я ничего не имею против сборщиков мусора, которые останавливают мир.

Заранее спасибо, Yoric

Answer 1

Документы LLVM говорят, что он не поддерживает многопоточные коллекторы пока .

Как показывает матрица, LLVM инфраструктура сбора мусора уже подходит для широкого спектра коллекционеры, но не в настоящее время распространяться на многопоточные программы. это будет добавлено в будущем, как там это интерес.

В документах говорится, что для многопоточной сборки мусора вам нужно остановить мир, и это непереносимая вещь:

Резьбовой Обозначает многопоточный мутатор; коллектор должен остановить мутатор ("остановить мир") перед анализ достижимости начала. Остановка многопоточного мутатора является сложная проблема. Это вообще требует сильно специфичного для платформы кода во время выполнения и производства тщательно разработанный машинный код на безопасные точки.

Однако, общее состояние между потоками является неприятной проблемой масштабирования. Если ваш язык взаимодействует исключительно посредством передачи сообщений между «задачами», и поэтому между рабочими потоками не было общего состояния, то вы можете использовать сборщик для каждого потока для кучи для каждого потока?

Answer 2

Цитаты, которые привел Уилл, касаются внутренней поддержки LC для GC, где вы дополняете LLVM с помощью кода C ++, рассказывающего, как обходить стек, интерпретировать кадры стека, вставлять барьеры чтения и записи и так далее. Основная цель моего HLVM проекта - стать полезной с минимальными усилиями и рисками, поэтому я решил использовать теневой стек для «нежелательной среды», чтобы избежать взлома незрелых внутренних компонентов LLVM. Следовательно, эти заявления о внутренней поддержке LC LMV для GC не применяются к сборщику мусора HLVM , поскольку он вообще не использует эту инфраструктуру. Мои результаты чрезвычайно убедительны: вы можете достичь превосходной производительности с минимальными усилиями ( последовательная производительность и параллельная производительность ).

Я полагаю, HLVM уже работает "из коробки" в Unix, включая Mac OS X, поскольку для него требуются только потоки POSIX. Я категорически не согласен с утверждением о том, что написать сборщик мусора "стоп-мир" сложно: мне потребовалось 5 дней, чтобы написать многоядерный сборщик мусора из 100 строк, и я почти ничего не знаю о компьютерах. Я не могу поверить, что было бы трудно портировать на Windows либо.