Сборка мусора (информатика) - Garbage collection (computer science)

Эта статья посвящена сборке мусора при управлении памятью. О сборке мусора на твердотельном диске см. сборка мусора (SSD).
Для использования в других целях см. Сборка мусора (значения).
Остановите и скопируйте сборку мусора в Архитектура Лиспа:[1] Память делится на работающий и свободный объем памяти; новые объекты (минусы пары) выделяются в первом. Когда он заполнен (изображен), выполняется сборка мусора: все структуры данных, которые все еще используются, обнаруживаются с помощью трассировки указателя и копируются в последовательные места в свободной памяти ...
... После этого содержимое рабочей памяти отбрасывается в пользу сжатой копии, а роль работающий и свободный память обмениваются (изображаются).

В Информатика, вывоз мусора (GC) является формой автоматического управление памятью. В уборщик мусора, или просто коллектор, попытки вернуть мусор, или память занята объекты которые больше не используются программа. Сборку мусора изобрел американский ученый-компьютерщик Джон Маккарти около 1959 г., чтобы упростить ручное управление памятью в Лисп.[2]

Сборка мусора избавляет программиста от выполнения ручное управление памятью где программист указывает, какие объекты освободить и вернуть в систему памяти и когда это сделать. Другие аналогичные методы включают: распределение стека, региональный вывод владение памятью и сочетание нескольких методов. Сборка мусора может занимать значительную часть общего времени обработки в программе и, как результат, может иметь значительное влияние на спектакль.

Ресурсы кроме памяти, такие как сетевые розетки, база данных ручки, окна взаимодействия с пользователем, файл и дескрипторы устройств обычно не обрабатываются сборкой мусора. Методы используется для управления такими ресурсами, в частности деструкторы, может хватить и для управления памятью, не оставляя необходимости в сборке мусора. Некоторые системы сборки мусора позволяют ассоциировать такие другие ресурсы с областью памяти, которая при сборе приводит к восстановлению этих ресурсов.

Принципы

Основные принципы сборки мусора - найти в программе объекты данных, к которым невозможно будет получить доступ в будущем, и освободить ресурсы, используемые этими объектами.

Много языки программирования требуется сборка мусора как часть спецификация языка (Например, Ява, C #, D,[3] Идти и большинство языки сценариев ) или эффективно для практической реализации (например, формальные языки, такие как лямбда-исчисление ); это, как говорят, языки со сборкой мусора. Другие языки были разработаны для использования с ручным управлением памятью, но для них доступны реализации со сборкой мусора (например, C и C ++ ). Некоторые языки, например Ада, Модула-3, и C ++ / CLI, разрешить сборку мусора и ручное управление памятью сосуществовать в одном приложении, используя отдельные кучи для собранных и управляемых вручную объектов; другие, как D, собираются мусором, но позволяют пользователю вручную удалять объекты, а также полностью отключать сборку мусора, когда требуется скорость.

При интеграции сборки мусора в язык компилятор и система времени выполнения дает возможность гораздо более широкий выбор методов,[нужна цитата ] постфактум Существуют системы ГХ, такие как Автоматический подсчет ссылок (ARC), включая те, которые не требуют перекомпиляции. (Post-hoc GC иногда выделяют как сбор помета.) Сборщик мусора почти всегда будет тесно интегрирован с распределитель памяти.

Преимущества

Сборка мусора освобождает программиста от ручной работы с освобождением памяти. В результате определенные категории ошибки устраняются или существенно сокращаются:

  • Висячий указатель ошибки, которые возникают, когда часть памяти освобождается, пока еще есть указатели к нему, и один из этих указателей разыменованный. К тому времени память могла быть переназначена для другого использования с непредсказуемыми результатами.
  • Двойные бесплатные ошибки, которые возникают, когда программа пытается освободить область памяти, которая уже была освобождена и, возможно, уже была выделена снова.
  • Определенные виды утечки памяти, в котором программе не удается освободить память, занятую объектами, ставшими недоступен, что может привести к истощению памяти. (Обычно сборка мусора[ВОЗ? ] не имеет дело с неограниченным накоплением данных, которые достижимы, но которые фактически не будут использоваться программой.)
  • Эффективное внедрение постоянные структуры данных

Некоторые из ошибок, устраняемых сборкой мусора, имеют последствия для безопасности.

Недостатки

Как правило, сборка мусора имеет определенные недостатки, в том числе потребление дополнительных ресурсов, снижение производительности, возможные задержки в выполнении программы и несовместимость с ручным управлением ресурсами.

Сборка мусора требует вычислительных ресурсов для принятия решения о том, какую память освободить, даже если программист, возможно, уже знал эту информацию. Штраф за удобство отсутствия аннотации времени жизни объекта вручную в исходном коде составляет накладные расходы, что может привести к снижению или неравномерной производительности.[4] В рецензируемой статье 2005 года был сделан вывод, что GC требуется в пять раз больше памяти, чтобы компенсировать эти накладные расходы и работать так же быстро, как явное управление памятью.[5] Взаимодействие с эффектами иерархии памяти может сделать эти накладные расходы невыносимыми в обстоятельствах, которые трудно предсказать или обнаружить при обычном тестировании. Влияние на производительность также было названо Apple причиной отказа от внедрения сборки мусора в iOS несмотря на то, что это самая желанная функция.[6]

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

Современные реализации GC пытаются минимизировать блокировку "останови мир "тормозит, выполняя как можно больше работы в фоновом режиме (т.е. в отдельном потоке), например, отмечая недостижимые экземпляры мусора, пока процесс приложения продолжает работать. Несмотря на эти улучшения, например в Парадигма .NET CLR по-прежнему очень трудно поддерживать большие кучи (миллионы объектов) с резидентными объектами, которые продвигаются до более старых поколений без заметных задержек (иногда до нескольких секунд).

Необходимость в явном ручном управлении ресурсами (выпуск / закрытие) для ресурсов без GC на объектно-ориентированном языке становится переходной для композиции. То есть: в недетерминированной системе сборки мусора, если для ресурса или подобного ресурсу объекта требуется ручное управление ресурсами (выпуск / закрытие), и этот объект используется как «часть» другого объекта, то составной объект также станет ресурсоподобный объект, который сам требует ручного управления ресурсами (выпуск / закрытие).

Стратегии

Отслеживание

Основная статья: Отслеживание сборки мусора

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

Подсчет ссылок

Основная статья: Подсчет ссылок

Сборка мусора с подсчетом ссылок - это когда каждый объект подсчитывает количество ссылок на него. Мусор идентифицируется по нулевому счетчику ссылок. Счетчик ссылок на объект увеличивается при создании ссылки на него и уменьшается при уничтожении ссылки. Когда счетчик достигает нуля, память объекта восстанавливается.[7]

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

Подсчет ссылок имеет ряд недостатков; Обычно это можно решить или смягчить с помощью более сложных алгоритмов:

Циклы
Если два или более объекта ссылаются друг на друга, они могут создать цикл, в котором ни один из них не будет собираться, поскольку их взаимные ссылки никогда не позволяют их счетчикам ссылок становиться равными нулю. Некоторые системы сбора мусора, использующие подсчет ссылок (например, CPython ) использовать специальные алгоритмы обнаружения цикла для решения этой проблемы.[8] Другая стратегия - использовать слабые ссылки для "обратных указателей", которые создают циклы. При подсчете ссылок слабая ссылка аналогична слабой ссылке при отслеживании сборщика мусора. Это специальный объект ссылки, существование которого не увеличивает счетчик ссылок объекта ссылки. Более того, слабая ссылка безопасна в том смысле, что когда объект-референт становится мусором, любая слабая ссылка на него упущения, вместо того, чтобы оставаться висящим, что означает, что он превращается в предсказуемое значение, такое как пустая ссылка.
Накладные расходы на пространство (количество ссылок)
Подсчет ссылок требует, чтобы для каждого объекта было выделено пространство для хранения его счетчика ссылок. Счетчик может храниться рядом с памятью объекта или в дополнительной таблице где-то еще, но в любом случае каждый отдельный объект со счетчиком ссылок требует дополнительного хранилища для своего счетчика ссылок. Для этой задачи обычно используется пространство памяти размером с указатель без знака, что означает, что для каждого объекта необходимо выделить 32 или 64 бита хранилища счетчика ссылок. В некоторых системах можно уменьшить эти накладные расходы, используя помеченный указатель для хранения счетчика ссылок в неиспользуемых областях памяти объекта. Часто архитектура фактически не позволяет программам получать доступ ко всему диапазону адресов памяти, которые могут быть сохранены в ее собственном указателе размера; определенное количество старших битов адреса либо игнорируется, либо должно быть равно нулю. Если объект надежно имеет указатель в определенном месте, счетчик ссылок может храниться в неиспользуемых битах указателя. Например, каждый объект в Цель-C имеет указатель на свой учебный класс в начале своей памяти; на ARM64 архитектура с использованием IOS 7, 19 неиспользуемых битов этого указателя класса используются для хранения счетчика ссылок на объект.[9][10]
Накладные расходы на скорость (увеличение / уменьшение)
В наивных реализациях каждое присвоение ссылки и каждая ссылка, выходящая за пределы области видимости, часто требует модификации одного или нескольких счетчиков ссылок. Однако в общем случае, когда ссылка копируется из переменной внешней области видимости во внутреннюю переменную области видимости, так что время жизни внутренней переменной ограничено временем жизни внешней, приращение ссылки может быть исключено. Внешняя переменная «владеет» ссылкой. В языке программирования C ++ этот прием легко реализуется и демонстрируется с использованием const Рекомендации. Подсчет ссылок в C ++ обычно реализуется с помощью "умные указатели "[11] чьи конструкторы, деструкторы и операторы присваивания управляют ссылками. Интеллектуальный указатель может быть передан по ссылке на функцию, что позволяет избежать необходимости копировать-конструировать новый интеллектуальный указатель (который увеличит счетчик ссылок при входе в функцию и уменьшит его при выходе). Вместо этого функция получает ссылку на интеллектуальный указатель, который производится недорого. Метод подсчета ссылок Дойча-Боброу основан на том факте, что большинство обновлений счетчика ссылок фактически генерируются ссылками, хранящимися в локальных переменных. Он игнорирует эти ссылки, только подсчитывая ссылки в куче, но перед тем, как объект с нулевым счетчиком ссылок может быть удален, система должна проверить с помощью сканирования стека и зарегистрировать, что никакой другой ссылки на него еще не существует. Дальнейшее существенное снижение накладных расходов на обновления счетчиков может быть получено путем объединения обновлений, введенного Леванони и Петранк.[12][13] Рассмотрим указатель, который в заданном интервале выполнения обновляется несколько раз. Сначала он указывает на объект O1, затем к объекту O2, и так далее, пока в конце интервала он не укажет на какой-то объект На. Алгоритм подсчета ссылок обычно выполняется rc (O1) -, rc (O2) ++, rc (O2) -, rc (O3) ++, rc (O3) -, ..., rc (Вкл) ++. Но большинство этих обновлений избыточны. Для правильной оценки счетчика ссылок в конце интервала достаточно выполнить rc (O1) - и rc (Вкл) ++. Леванони и Петранк измерили устранение более 99% обновлений счетчиков в типичных тестах Java.
Требуется атомарность
При использовании в многопоточный среды, эти изменения (увеличение и уменьшение), возможно, потребуется атомарные операции Такие как сравнивать и менять местами, по крайней мере, для любых объектов, которые используются совместно или потенциально могут использоваться несколькими потоками. Атомарные операции дороги для мультипроцессора и даже дороже, если их нужно эмулировать с помощью программных алгоритмов. Эту проблему можно избежать, добавив счетчики ссылок для каждого потока или процессора и обращаясь к глобальному счетчику ссылок только тогда, когда локальные счетчики ссылок становятся или больше не равны нулю (или, альтернативно, используя двоичное дерево счетчиков ссылок, или даже отказ от детерминированного уничтожения в обмен на отсутствие глобального счетчика ссылок вообще), но это добавляет значительные накладные расходы на память и, таким образом, имеет тенденцию быть полезным только в особых случаях (например, при подсчете ссылок модулей ядра Linux ).
Объединение обновлений Леванони и Петранк [12][13] может использоваться для исключения всех атомарных операций с барьера записи. Счетчики никогда не обновляются потоками программы в процессе выполнения программы. Они изменяются только сборщиком, который выполняется как отдельный дополнительный поток без синхронизации. Этот метод может использоваться в качестве механизма остановки для параллельных программ, а также с параллельным сборщиком подсчета ссылок.
Не в реальном времени
Наивные реализации подсчета ссылок, как правило, не обеспечивают поведения в реальном времени, поскольку любое присвоение указателя потенциально может привести к рекурсивному освобождению ряда объектов, ограниченных только общим размером выделенной памяти, в то время как поток не может выполнять другую работу. Этой проблемы можно избежать, делегируя освобождение объектов, счетчик ссылок которых упал до нуля, другим потокам за счет дополнительных накладных расходов.

Анализ побега

Основная статья: Анализ побега

Анализ побега это метод времени компиляции, который может преобразовывать распределение кучи к выделение стека, тем самым уменьшая объем сборки мусора. Этот анализ определяет, доступен ли объект, размещенный внутри функции, вне ее. Если обнаруживается, что локальное для функции распределение доступно для другой функции или потока, то говорят, что это выделение «ускользает» и не может быть выполнено в стеке. В противном случае объект может быть выделен непосредственно в стеке и освобожден, когда функция вернется, минуя кучу и связанные с ней затраты на управление памятью.[14]

Отметка времени и сердцебиение

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

Доступность

Вообще говоря, языки программирования более высокого уровня с большей вероятностью будут иметь сборку мусора в качестве стандартной функции. В некоторых языках, в которых нет встроенной сборки мусора, ее можно добавить через библиотеку, как в случае с Сборщик мусора Boehm для C и C ++.

Наиболее функциональные языки программирования, Такие как ML, Haskell, и APL, имеют встроенную сборку мусора. Лисп особенно примечателен как первые функциональный язык программирования и первый язык, который представил сборку мусора.[15]

Другие динамические языки, такие как Рубин и Юля (но нет Perl 5 или PHP до версии 5.3,[16] которые оба используют подсчет ссылок), JavaScript и ECMAScript также склонны использовать GC. Объектно-ориентированного программирования языки, такие как Болтовня и Ява обычно обеспечивают интегрированную сборку мусора. Заметными исключениями являются C ++ и Delphi который имеет деструкторы.

БАЗОВЫЙ

Исторически сложилось так, что языки, предназначенные для начинающих, такие как БАЗОВЫЙ и Логотип, часто использовали сборку мусора для типов данных переменной длины, размещенных в куче, таких как строки и списки, чтобы не обременять программистов ручным управлением памятью. На ранних микрокомпьютерах с их ограниченной памятью и медленными процессорами сборка мусора BASIC часто могла вызывать явно случайные, необъяснимые паузы в процессе работы программы.

Некоторые интерпретаторы BASIC, такие как Applesoft BASIC на Яблоко II семейство, многократно просканировало строковые дескрипторы для строки с наивысшим адресом, чтобы сжать ее в сторону верхней памяти, в результате На2) производительность, которая может вводить минутные паузы в выполнении программ с интенсивным использованием строк. Заменяющий сборщик мусора для Applesoft BASIC опубликован в Звоните-A.P.P.L.E. (Январь 1981 г., страницы 40–45, Рэнди Виггинтон ) идентифицировал группу строк при каждом проходе по куче, что резко сокращало время сбора. BASIC.System, выпущенный с ProDOS в 1983 году предоставил оконный сборщик мусора для BASIC, который сократил большинство сборок до долей секунды.

Цель-C

В то время как Цель-C традиционно не было сборки мусора, с выпуском OS X 10.5 в 2007 яблоко введена сборка мусора для Цель-C 2.0 с использованием собственного сборщика времени выполнения.[17]Однако с выпуском 2012 г. OS X 10.8, сборка мусора устарела в пользу LLVM с автоматический счетчик ссылок (ARC), который был представлен с OS X 10.7.[18] Более того, с мая 2015 года Apple даже запрещает использование сборки мусора для новых приложений OS X в Магазин приложений.[19][20] За iOS сборка мусора никогда не применялась из-за проблем с откликом и производительностью приложений;[6][21] вместо этого iOS использует ARC.[22][23]

Ограниченная среда

Сборка мусора редко используется на встроенный или систем реального времени из-за обычной потребности в очень жестком контроле за использованием ограниченных ресурсов. Однако были разработаны сборщики мусора, совместимые со многими ограниченными средами.[24] Microsoft .NET Micro Framework, .NET nanoFramework и Платформа Java, Micro Edition представляют собой встроенные программные платформы, которые, как и их более крупные собратья, включают сборку мусора.

Сборщики мусора для Java

Некоторые популярные сборщики мусора, доступные в Java JDK, включают:

Сравнение сборщиков мусора - сложная задача, и у разных приложений могут быть самые разные потребности. Среди важных факторов - накладные расходы на производительность (как приложение замедляется сборщиком мусора), время остановок, частота и распределение (когда сборщик мусора замораживает приложение, сколько времени требуется для завершения процесса, и как часто это явление происходит), масштабируемость, производительность выделения памяти, ...[26]

Использование во время компиляции

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

Эта форма сборки мусора была изучена в Язык программирования Mercury,[27] и он получил большее распространение с появлением LLVM с автоматический счетчик ссылок (ARC) в экосистему Apple (iOS и OS X) в 2011 году.[22][23][19]

Системы реального времени

Были разработаны инкрементные, параллельные сборщики мусора в реальном времени, такие как Бейкера алгоритм или Либерман алгоритм.[28][29][30]

В алгоритме Бейкера выделение выполняется в любой половине одной области памяти. Когда он заполняется наполовину, выполняется сборка мусора, которая перемещает живые объекты в другую половину, а оставшиеся объекты неявно освобождаются. Запущенная программа («мутатор») должна проверить, что любой объект, на который она ссылается, находится в правильной половине, и, если нет, переместить его, пока фоновая задача находит все объекты.[31]

Сборка мусора поколений схемы основаны на эмпирическом наблюдении, что большинство объектов умирают молодыми. При сборке мусора по поколениям сохраняются две или более области распределения (поколения), которые хранятся отдельно в зависимости от возраста объекта. Новые объекты создаются в «молодом» поколении, которое регулярно собирается, и когда поколение заполнено, объекты, на которые все еще ссылаются из более старых регионов, копируются в следующее старшее поколение. Иногда выполняется полное сканирование.

Немного компьютерные архитектуры на языках высокого уровня включить аппаратную поддержку для сборки мусора в реальном времени.

Большинство реализаций сборщиков мусора в реальном времени используют отслеживание.[нужна цитата ] Такие сборщики мусора в реальном времени встречаются жесткий режим реального времени ограничения при использовании с операционной системой реального времени.[32]

Смотрите также

Рекомендации

  1. ^ Гарольд Абельсон и Джеральд Джей Сассман и Джули Сассман (2016). Структура и интерпретация компьютерных программ (PDF) (2-е изд.). Кембридж, Массачусетс: MIT Press. Здесь: с.734-736
  2. ^ Маккарти, Джон (1960). "Рекурсивные функции символьных выражений и их машинное вычисление, Часть I". Коммуникации ACM. 3 (4): 184–195. Дои:10.1145/367177.367199. S2CID  1489409. Получено 2009-05-29.
  3. ^ "Обзор - язык программирования D". dlang.org. Цифровой Марс. Получено 2014-07-29.
  4. ^ Цорн, Бенджамин (1993-01-22). «Измеренная стоимость консервативной сборки мусора». Практика и опыт работы с программным обеспечением. Департамент компьютерных наук, Университет Колорадо в Боулдере. 23 (7): 733–756. CiteSeerX  10.1.1.14.1816. Дои:10.1002 / spe.4380230704. S2CID  16182444.
  5. ^ Мэтью Герц; Эмери Д. Бергер (2005). «Количественная оценка производительности сборки мусора по сравнению с явным управлением памятью» (PDF). Материалы 20-й ежегодной конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям - OOPSLA '05. п. 313. Дои:10.1145/1094811.1094836. ISBN  1595930310. S2CID  6570650. Получено 2015-03-15.
  6. ^ а б «Начало работы с инструментами разработчика - сессия 300» (PDF). WWDC 2011. Apple, Inc. 2011-06-24. Получено 2015-03-27.
  7. ^ Подсчет ссылок Сборка мусора
  8. ^ «Количество ссылок». Расширение и встраивание интерпретатора Python. 2008-02-21. Получено 2014-05-22.
  9. ^ Майк Эш. «Пятничные вопросы и ответы 2013-09-27: ARM64 и вы». mikeash.com. Получено 2014-04-27.
  10. ^ "Hamster Emporium: [объяснение объекта]: isa без указателя". Sealiesoftware.com. 2013-09-24. Получено 2014-04-27.
  11. ^ RAII, динамические объекты и фабрики на C ++, Роланд Пибингер, 3 мая 2005 г.
  12. ^ а б Йоси Леванони, Эрез Петранк (2001). "Сборщик мусора с подсчетом ссылок на лету для java". Материалы 16-й конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям. OOPSLA 2001. С. 367–380. Дои:10.1145/504282.504309.
  13. ^ а б Йоси Леванони, Эрез Петранк (2006). "Сборщик мусора с подсчетом ссылок на лету для java". ACM Trans. Программа. Lang. Syst. 28: 31–69. CiteSeerX  10.1.1.15.9106. Дои:10.1145/1111596.1111597. S2CID  14777709.
  14. ^ Саланьяк, G; и другие. (2005-05-24). «Анализ быстрого выхода для управления памятью по регионам». Электронные заметки по теоретической информатике. 131: 99–110. Дои:10.1016 / j.entcs.2005.01.026.
  15. ^ Чисналл, Дэвид (11.01.2011). Влиятельные языки программирования, часть 4: Лисп.
  16. ^ «PHP: соображения производительности». php.net. Получено 2015-01-14.
  17. ^ Objective-C 2.0 Обзор
  18. ^ Mac OS X 10.7 Lion: обзор Ars Technica Джон Сиракуза (20 июля 2011 г.)
  19. ^ а б Apple заявляет, что к маю производители приложений для Mac должны перейти на управление памятью ARC от AppleInsider (20 февраля 2015 г.)
  20. ^ Сишон, Вальдемар (21 февраля 2015). «Магазин приложений: программа Apple по сборке мусора». Heise.de. Получено 2015-03-30.
  21. ^ Сильва, Драгоценный (2014-11-18). «iOS 8 против Android 5.0 Lollipop: Apple убивает Google эффективностью памяти». International Business Times. Получено 2015-04-07.
  22. ^ а б Роб Напье, Мугунт Кумар (2012-11-20). Программирование на iOS 6 выходит за рамки. Джон Уайли и сыновья. ISBN  9781118449974. Получено 2015-03-30.
  23. ^ а б Круз, Хосе Р. (2012-05-22). «Автоматический подсчет ссылок на iOS». Доктор Доббс. Получено 2015-03-30.
  24. ^ Фу, Вэй; Хаузер, Карл (2005). «Фреймворк для сборки мусора в реальном времени для встроенных систем». Материалы семинара 2005 г. по программному обеспечению и компиляторам для встраиваемых систем - SCOPES '05. С. 20–26. Дои:10.1145/1140389.1140392. ISBN  1595932070. S2CID  8635481.
  25. ^ Тене, Гил; Айенгар, Баладжи; Вольф, Майкл (2011). «C4: непрерывно работающий коллектор уплотнения» (PDF). ISMM '11: Материалы международного симпозиума по управлению памятью. Дои:10.1145/1993478. ISBN  9781450302630.
  26. ^ Хирн, Майк (2019-06-09). «Современная вывозка мусора: Часть 2». Середина. Получено 2019-09-09.
  27. ^ Мазур, Нэнси (май 2004 г.). Сборка мусора во время компиляции для декларативного языка Mercury (PDF) (Тезис). Katholieke Universiteit Leuven.
  28. ^ Хюльсберген, Лоренц; Уинтерботтом, Фил (1998). «Очень параллельная сборка мусора с метками и очисткой без точной синхронизации» (PDF). Материалы Первого международного симпозиума по управлению памятью - ISMM '98. С. 166–175. Дои:10.1145/286860.286878. ISBN  1581131143. S2CID  14399427.
  29. ^ «FAQ по GC».
  30. ^ Либерман, Генри; Хьюитт, Карл (1983). «Сборщик мусора в реальном времени, основанный на времени жизни объектов». Коммуникации ACM. 26 (6): 419–429. Дои:10.1145/358141.358147. HDL:1721.1/6335. S2CID  14161480.
  31. ^ Бейкер, Генри Г. (1978). «Обработка списков в реальном времени на последовательном компьютере». Коммуникации ACM. 21 (4): 280–294. Дои:10.1145/359460.359470. HDL:1721.1/41976. S2CID  17661259. смотрите также описание
  32. ^ Макклоски, Бэкон, Ченг, Гроув.«Staccato: параллельный и параллельный сборщик мусора в реальном времени для мультипроцессоров». 2008.

дальнейшее чтение

внешняя ссылка