Сборка мусора переопределена в LLVM 3?

Question

Я читал о том факте, что LLVM v3 использует статический анализ кода для реализации своего рода автоматической сборки мусора, которая подготавливается и выполняется во время компиляции.

Если компилятор статически вставляет, сохраняет и освобождает, тобольше не нужен компонент времени выполнения для сборки мусора или что?

Это правда?Будет ли он работать как замена обычной сборки мусора на iOS и OS X?Не ясно, что произойдет ..

Стоит ли полагаться на этот тип "статической сборки мусора"?

Answer 1

Это интересный вопрос: может ли статический анализатор реализовать полную систему сбора мусора?

Ответ, по-видимому, будет отрицательным.Единственный способ реализовать сборку мусора - это знать, что выделенный фрагмент памяти (например, экземпляр объекта) больше не может использоваться.В GC времени выполнения это знание приобретается (эффективно) путем сканирования стека и кучи.Выполнение этого во время компиляции потребовало бы анализа всех возможных путей кода в системе, чтобы определить, где при его выполнении конкретное распределение больше не будет достижимо.Это эквивалентно проблеме остановки.Тем не менее, LLVM утверждает, что поддерживает как минимум ограниченную форму автоматического подсчета ссылок (вставка сохранения / выпуска) для вас.См. http://developer.apple.com/technologies/ios5/. Я подозреваю, что то, что делает LLVM, это не полный сборщик мусора, он использует статический анализатор, чтобы найти, когда все ссылки на объект выходят из области видимости, и вставляет для вас соответствующие сохранения / выпуски.Подсчет ссылок происходит во время выполнения , как и раньше.Я очень сомневаюсь, что он будет выполнять автоматическое free -обнаружение блоков malloc'd для вас.

Если он работает так, как было объявлено на общедоступном сайте выше, я бы сказал, используйте его.

Answer 2

Если компилятор статически вставляет, сохраняет и освобождает, тогда больше не требуется никакого компонента времени выполнения для сборки мусора или что?

ARC означает «Автоматический подсчет ссылок» и, следовательно, прибегает к подсчету ссылок (RC) в целом. RC является одной из самых старых форм сбора мусора, начиная с 1960 года, и редко используется на практике, потому что он очень медленный, имеет неограниченные паузы и неточен, потому что он пропускает циклы.

RC медленный, потому что счетчики ссылок увеличиваются и уменьшаются каждый раз, когда вы обрабатываете ссылку на объект (например, считываете ссылку из кучи или записываете ее в кучу), а подсчет ссылок, ориентированный на поток, должен корректировать счет с использованием атомарного приращения и уменьшения операции. Наивный подсчет ссылок (например, shared_ptr в C ++) примерно в 10 раз медленнее, чем отслеживание сборки мусора. ARC использует статический анализ для удаления некоторых из этих приращений и уменьшений счетчиков, которые улучшат производительность, но я не знаю каких-либо критериев и серьезно сомневаюсь, что результат конкурентоспособен по сравнению, например, с JVM или CLR (оба из которых исключены подсчет ссылок давным-давно, потому что они обнаружили, что отслеживание сбора мусора намного быстрее и точнее)

Answer 3

То, что вы слышали, верно.См. «Автоматический подсчет ссылок» по адресу http://developer.apple.com/technologies/ios5/.. Если вы являетесь зарегистрированным разработчиком, вы можете прочитать гораздо больше об ARC в недавно выпущенных документах «Что нового» (под NDA).