Сборщики мусора для многоядерного llvm?
Я смотрел на LLVM в течение достаточно долгого времени как на новый бэкенд для языка, который я в настоящее время реализую. Это, кажется, имеет хорошую производительность, довольно высокоуровневые API поколения, достаточно поддержки низкого уровня для оптимизации экзотической оптимизации. Кроме того, и хотя я не проверил его сам, Apple, кажется, успешно продемонстрировала использование LLVM для собравших "мусор" многоядерных программ.
Пока неплохо. Поскольку я интересуюсь и сборкой "мусора" и многоядерный, следующий шаг должен был бы выбрать LLVM многоядерно-способный сборщик мусора. Который приносит мне к вопросу: что доступно? Я знаю о работе HLVM Jon Harrop, но это об этом.
Обратите внимание, что мне нужно межплатформенный, таким образом, GC Apple, вероятно, не, что я ищу (если нет межплатформенная версия). Также обратите внимание, что у меня ничего нет против stop-world сборщиков мусора.
Заранее спасибо, Yoric
2 ответа
В документации LLVM говорится, что он еще не поддерживает многопоточные сборщики .
Как видно из матрицы, инфраструктура сборки мусора LLVM уже подходит для большого количества сборщиков, но в настоящее время не распространяется на многопоточные программы. . Этот будет добавлен в будущем, так как есть интерес.
В документации действительно сказано, что для выполнения многопоточной сборки мусора вам нужно остановить мир, и что это непереносимая вещь:
Threaded Обозначает многопоточный мутатор; сборщик должен остановить мутатор ("остановить мир") до того, как начать анализ достижимости. Остановка многопоточного мутатора - это сложная проблема. Обычно для этого требуется во время выполнения код, строго зависящий от платформы , а также создание тщательно разработанного машинного кода в безопасных точках.
Однако общее состояние между потоками - неприятная проблема масштабирования. Если ваш язык общается исключительно посредством передачи сообщений между «задачами» и, следовательно, между рабочими потоками не было общего состояния, то вы могли бы использовать сборщик для каждого потока для кучи потока?
Цитаты, которые привел Уилл, касаются встроенной поддержки GC в LLVM, где вы дополняете LLVM кодом C ++, рассказывая ему, как обходить стек, интерпретировать кадры стека, вводить барьеры чтения и записи и так далее. Основная цель моего проекта HLVM - сделать его полезным с минимальными усилиями и рисками, поэтому я решил использовать теневой стек для «несовместимой среды», чтобы избежать взлома незрелой внутренней части LLVM. Следовательно, эти утверждения о внутренней поддержке GC в LLVM не относятся к сборщику мусора HLVM , потому что он вообще не использует эту инфраструктуру. Мои результаты чрезвычайно убедительны: вы можете добиться отличной производительности с минимальными усилиями ( последовательная производительность и параллельная производительность ).
Я считаю, что HLVM уже готов к работе в Unix, включая Mac OS X, потому что для этого требуются только потоки POSIX. Я категорически не согласен с утверждением, что написать сборщик мусора с остановкой мира сложно: мне потребовалось 5 дней, чтобы написать 100-строчный многоядерный сборщик мусора, а я почти ничего не знаю о компьютерах. Не могу поверить, что это будет сложно портировать на Windows.