stringtranslate.com

Сбор мусора (информатика)

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

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

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

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

Обзор

Многие языки программирования требуют сборки мусора, либо как часть спецификации языка (например, RPL , Java , C# , D , [5] Go и большинство языков сценариев ), либо эффективно для практической реализации (например, формальные языки, такие как лямбда-исчисление ). [6] Говорят, что это языки со сборкой мусора . Другие языки, такие как C и C++ , были разработаны для использования с ручным управлением памятью, но имеют доступные реализации со сборкой мусора. Некоторые языки, такие как Ada , Modula-3 и C++/CLI , позволяют как сборке мусора, так и ручному управлению памятью сосуществовать в одном приложении, используя отдельные кучи для собранных и управляемых вручную объектов. Другие же, такие как D , имеют сборку мусора, но позволяют пользователю вручную удалять объекты или даже полностью отключать сборку мусора, когда требуется скорость. [7]

Хотя многие языки интегрируют GC в свои компиляторы и системы времени выполнения , существуют также пост-хок системы GC, такие как Automatic Reference Counting (ARC). Некоторые из этих пост-хок систем GC не требуют перекомпиляции. [8]

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

GC освобождает программиста от ручного освобождения памяти. Это помогает избежать некоторых видов ошибок : [9]

Недостатки

Сборщик мусора использует вычислительные ресурсы для принятия решения о том, какую память освободить. Таким образом, штрафом за удобство не аннотировать время жизни объекта вручную в исходном коде являются накладные расходы , которые могут ухудшить производительность программы. [12] В рецензируемой статье 2005 года сделан вывод о том, что сборщику мусора требуется в пять раз больше памяти, чтобы компенсировать эти накладные расходы и работать так же быстро, как та же программа, использующая идеальное явное управление памятью. Однако сравнение проводится с программой, сгенерированной путем вставки вызовов освобождения с помощью оракула , реализованного путем сбора трассировок из программ, запущенных под профилировщиком , и программа верна только для одного конкретного выполнения программы. [13] Взаимодействие с эффектами иерархии памяти может сделать эти накладные расходы недопустимыми в обстоятельствах, которые трудно предсказать или обнаружить при обычном тестировании. Влияние на производительность было указано Apple в качестве причины отказа от внедрения сборки мусора в iOS , несмотря на то, что это самая желанная функция. [14]

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

Стратегии

Трассировка

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

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

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

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

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

Циклы
Если два или более объектов ссылаются друг на друга, они могут создать цикл, в результате чего ни один из них не будет собран, поскольку их взаимные ссылки никогда не позволят их счетчикам ссылок стать нулевыми. Некоторые системы сборки мусора, использующие подсчет ссылок (например, в CPython ), используют специальные алгоритмы обнаружения циклов для решения этой проблемы. [16] Другая стратегия заключается в использовании слабых ссылок для «обратных указателей», которые создают циклы. При подсчете ссылок слабая ссылка похожа на слабую ссылку при трассирующем сборщике мусора. Это особый ссылочный объект, существование которого не увеличивает счетчик ссылок ссылаемого объекта. Более того, слабая ссылка безопасна в том смысле, что когда ссылаемый объект становится мусором, любая слабая ссылка на него прекращается , а не остается висячей, что означает, что она превращается в предсказуемое значение, такое как нулевая ссылка.
Накладные расходы (количество ссылок)
Подсчет ссылок требует выделения места для каждого объекта для хранения его счетчика ссылок. Счетчик может храниться рядом с памятью объекта или в боковой таблице где-то еще, но в любом случае каждый отдельный объект с подсчетом ссылок требует дополнительного хранилища для своего счетчика ссылок. Для этой задачи обычно используется пространство памяти размером с беззнаковый указатель, что означает, что для каждого объекта должно быть выделено 32 или 64 бита хранилища счетчика ссылок. В некоторых системах можно уменьшить эти накладные расходы, используя помеченный указатель для хранения счетчика ссылок в неиспользуемых областях памяти объекта. Часто архитектура фактически не позволяет программам получать доступ ко всему диапазону адресов памяти, которые могут храниться в его собственном размере указателя; определенное количество старших бит в адресе либо игнорируется, либо должно быть равно нулю. Если объект надежно имеет указатель в определенном месте, счетчик ссылок может храниться в неиспользуемых битах указателя. Например, каждый объект в Objective-C имеет указатель на свой класс в начале своей памяти; на архитектуре ARM64 с использованием iOS 7 19 неиспользуемых бит этого указателя класса используются для хранения счетчика ссылок объекта. [17] [18]
Скорость накладных расходов (увеличение/уменьшение)
В наивных реализациях каждое назначение ссылки и каждая ссылка, выпадающая из области видимости, часто требуют модификации одного или нескольких счетчиков ссылок. Однако в общем случае, когда ссылка копируется из внешней переменной области видимости во внутреннюю переменную области видимости, так что время жизни внутренней переменной ограничено временем жизни внешней, приращение ссылки может быть устранено. Внешняя переменная «владеет» ссылкой. В языке программирования C++ эта техника легко реализуется и демонстрируется с использованием ссылок const. Подсчет ссылок в C++ обычно реализуется с использованием « умных указателей » [19], чьи конструкторы, деструкторы и операторы присваивания управляют ссылками. Умный указатель может быть передан по ссылке в функцию, что позволяет избежать необходимости копирования-конструирования нового умного указателя (что увеличило бы счетчик ссылок при входе в функцию и уменьшило бы его при выходе). Вместо этого функция получает ссылку на умный указатель, который создается недорого. Метод подсчета ссылок Дойча-Боброва использует тот факт, что большинство обновлений счетчика ссылок фактически генерируются ссылками, хранящимися в локальных переменных. Он игнорирует эти ссылки, подсчитывая только ссылки в куче, но перед тем, как объект с нулевым счетчиком ссылок может быть удален, система должна проверить сканированием стека и зарегистрировать, что других ссылок на него больше не существует. Еще более существенное снижение накладных расходов на обновления счетчиков может быть получено путем объединения обновлений, введенного Леванони и Петранком . [20] [21] Рассмотрим указатель, который в заданном интервале выполнения обновляется несколько раз. Сначала он указывает на объект O1, затем на объект O2и так далее, пока в конце интервала он не укажет на некоторый объект On. Алгоритм подсчета ссылок обычно выполняет rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. Но большинство этих обновлений избыточны. Для того чтобы счетчик ссылок был правильно оценен в конце интервала, достаточно выполнить rc(O1)--и rc(On)++. Леванони и Петранк зафиксировали устранение более 99% обновлений счетчиков в типичных тестах производительности Java.
Требуется атомарность
При использовании в многопоточной среде эти изменения (инкремент и декремент) могут потребовать атомарных операций , таких как compare-and-swap , по крайней мере для любых объектов, которые являются общими или потенциально общими для нескольких потоков. Атомарные операции являются дорогостоящими на многопроцессорных системах и еще более дорогостоящими, если их приходится эмулировать с помощью программных алгоритмов. Можно избежать этой проблемы, добавив счетчики ссылок на поток или на ЦП и обращаясь к глобальному счетчику ссылок только тогда, когда локальные счетчики ссылок становятся или больше не равны нулю (или, в качестве альтернативы, используя двоичное дерево счетчиков ссылок или даже отказываясь от детерминированного уничтожения в обмен на отсутствие глобального счетчика ссылок вообще), но это добавляет значительные накладные расходы памяти и, таким образом, имеет тенденцию быть полезным только в особых случаях (например, оно используется при подсчете ссылок модулей ядра Linux). Объединение обновлений Леванони и Петранка [20] [21] может использоваться для устранения всех атомарных операций из барьера записи. Счетчики никогда не обновляются потоками программы в ходе выполнения программы. Они изменяются только сборщиком, который выполняется как один дополнительный поток без синхронизации. Этот метод может использоваться как механизм остановки мира для параллельных программ, а также с параллельным сборщиком подсчета ссылок.
Не в режиме реального времени
Наивные реализации подсчета ссылок обычно не обеспечивают поведение в реальном времени, поскольку любое назначение указателя может потенциально привести к рекурсивному освобождению ряда объектов, ограниченных только общим размером выделенной памяти, пока поток не сможет выполнять другую работу. Можно избежать этой проблемы, делегировав освобождение неиспользуемых объектов другим потокам, за счет дополнительных накладных расходов.

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

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

Доступность

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

Большинство функциональных языков программирования , таких как ML , Haskell и APL , имеют встроенную сборку мусора. Lisp особенно примечателен как первый функциональный язык программирования и первый язык, в котором была реализована сборка мусора. [23]

Другие динамические языки, такие как Ruby и Julia (но не Perl  5 или PHP до версии 5.3, [24] которые оба используют подсчет ссылок), JavaScript и ECMAScript также склонны использовать GC. Объектно-ориентированные языки программирования, такие как Smalltalk , RPL и Java, обычно предоставляют интегрированную сборку мусора. Известными исключениями являются C++ и Delphi , которые имеют деструкторы .

БАЗОВЫЙ

BASIC и Logo часто использовали сборку мусора для типов данных переменной длины, таких как строки и списки, чтобы не обременять программистов подробностями управления памятью. На Altair 8800 программы с большим количеством строковых переменных и небольшим пространством для строк могли вызывать длительные паузы из-за сборки мусора. [25] Аналогично алгоритм сборки мусора интерпретатора Applesoft BASIC многократно сканирует дескрипторы строк для строки с наивысшим адресом, чтобы сжать ее в сторону верхней памяти, что приводит к повышению производительности [26] и делает паузы от нескольких секунд до нескольких минут. [27] Заменяющий сборщик мусора для Applesoft BASIC Рэнди Виггинтона идентифицирует группу строк при каждом проходе по куче, что значительно сокращает время сборки. [28] BASIC.SYSTEM, выпущенный вместе с ProDOS в 1983 году, предоставляет оконный сборщик мусора для BASIC, который работает во много раз быстрее. [29]

Objective-C

В то время как Objective-C традиционно не имел сборки мусора, с выпуском OS X 10.5 в 2007 году Apple представила сборку мусора для Objective-C  2.0, используя сборщик времени выполнения собственной разработки. [30] Однако с выпуском OS X 10.8 в 2012 году сборка мусора была упразднена в пользу автоматического счетчика ссылок LLVM ( ARC), который был представлен в OS X 10.7 . [31] Более того, с мая 2015 года Apple даже запретила использование сборки мусора для новых приложений OS X в App Store . [32] [33] Для iOS сборка мусора никогда не вводилась из-за проблем с отзывчивостью и производительностью приложений; [14] [34] вместо этого iOS использует ARC. [35] [36]

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

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

Ява

В комплект Java JDK входят следующие сборщики мусора:

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

Сборка мусора во время компиляции — это форма статического анализа, позволяющая повторно использовать и восстанавливать память на основе инвариантов, известных во время компиляции.

Эта форма сборки мусора была изучена в языке программирования Mercury [40] и получила более широкое применение с введением автоматического счетчика ссылок (ARC) LLVM в экосистему Apple (iOS и OS X) в 2011 году. [35] [36] [32]

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

Были разработаны инкрементальные, параллельные и работающие в режиме реального времени сборщики мусора, например, Генри Бейкером и Генри Либерманом . [41] [42] [43]

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

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

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

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

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

Ссылки

  1. ^ Абельсон, Гарольд; Сассман, Джеральд Джей; Сассман, Джули (2016). Структура и интерпретация компьютерных программ (PDF) (2-е изд.). Кембридж, Массачусетс, США: MIT Press . стр. 734–736.
  2. ^ "Что такое сборка мусора (GC) в программировании?". Хранилище . Получено 2024-06-21 .
  3. ^ Маккарти, Джон (1960). «Рекурсивные функции символических выражений и их вычисление машиной, часть I». Сообщения ACM . 3 (4): 184–195. doi : 10.1145/367177.367199 . S2CID  1489409. Получено 29.05.2009 .
  4. ^ "Что такое сборка мусора (GC) в программировании?". SearchStorage . Получено 2022-10-17 .
  5. ^ "Обзор – Язык программирования D". dlang.org . Digital Mars . Получено 29.07.2014 .
  6. ^ Хеллер, Мартин (2023-02-03). "Что такое сборка мусора? Автоматизированное управление памятью для ваших программ". InfoWorld . Получено 2024-06-21 .
  7. ^ "Руководство по сборке мусора в программировании". freeCodeCamp.org . 2020-01-16 . Получено 2024-06-21 .
  8. ^ "Сборка мусора - язык программирования D". dlang.org . Получено 2022-10-17 .
  9. ^ "Сборка мусора". rebelsky.cs.grinnell.edu . Получено 2024-01-13 .
  10. ^ Хеллер, Мартин (2023-02-03). "Что такое сборка мусора? Автоматизированное управление памятью для ваших программ". InfoWorld . Получено 2024-06-21 .
  11. ^ Microsoft (2023-02-28). "Основы сборки мусора | Microsoft Learn" . Получено 2023-03-29 .
  12. ^ Зорн, Бенджамин (1993-01-22). «Измеренная стоимость консервативного сбора мусора». Программное обеспечение: практика и опыт . 23 (7). Кафедра компьютерных наук, Университет Колорадо в Боулдере : 733–756. CiteSeerX 10.1.1.14.1816 . doi :10.1002/spe.4380230704. S2CID  16182444. 
  13. ^ Герц, Мэтью; Бергер, Эмери Д. (2005). "Количественная оценка производительности сборки мусора по сравнению с явным управлением памятью" (PDF) . Труды 20-й ежегодной конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям - OOPSLA '05 . стр. 313–326. doi :10.1145/1094811.1094836. ISBN 1-59593031-0. S2CID  6570650. Архивировано (PDF) из оригинала 2012-04-02 . Получено 2015-03-15 .
  14. ^ ab "Developer Tools Kickoff – session 300" (PDF) . WWDC 2011 . Apple, Inc. 2011-06-24. Архивировано из оригинала (PDF) 2023-09-04 . Получено 2015-03-27 .
  15. ^ Microsoft (2009-01-27). "Сборка мусора с подсчетом ссылок" . Получено 2023-03-29 .
  16. ^ "Reference Counts". Расширение и встраивание интерпретатора Python . 2008-02-21 . Получено 2014-05-22 .
  17. ^ Эш, Майк. "Пятничные вопросы и ответы 2013-09-27: ARM64 и вы". mikeash.com . Получено 2014-04-27 .
  18. ^ "Hamster Emporium: [objc Explain]: Неуказательный isa". Sealiesoftware.com. 2013-09-24 . Получено 2014-04-27 .
  19. ^ Пибингер, Роланд (3 мая 2005 г.) [17 апреля 2005 г.]. «RAII, динамические объекты и фабрики в C++».
  20. ^ ab Леванони, Йосси; Петранк, Эрез (2001). «Сборщик мусора с подсчетом ссылок на лету для Java». Труды 16-й конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям . OOPSLA 2001. стр. 367–380. doi :10.1145/504282.504309.
  21. ^ ab Levanoni, Yossi; Petrank, Erez (2006). «Сборщик мусора с подсчетом ссылок на лету для Java». ACM Trans. Program. Lang. Syst . 28 : 31–69. CiteSeerX 10.1.1.15.9106 . doi :10.1145/1111596.1111597. S2CID  14777709. 
  22. ^ Салагнац, Гийом; Йовин, Серджио; Гарберветски, Диего (2005-05-24). «Быстрый анализ выхода для управления памятью на основе регионов». Электронные заметки по теоретической информатике . 131 : 99–110. doi : 10.1016/j.entcs.2005.01.026 .
  23. ^ Чисналл, Дэвид (12.01.2011). Влиятельные языки программирования, часть 4: Lisp.
  24. ^ "PHP: Вопросы производительности". php.net . Получено 2015-01-14 .
  25. ^ "Altair 8800 Basic 4.1 Reference Manual" (PDF) . The Vintage Technology Digital Archive . Апрель 1977. стр. 108. Архивировано (PDF) из оригинала 2021-06-29 . Получено 2021-06-29 .
  26. ^ "Я проделал некоторую работу по ускорению сборки строкового мусора в Applesoft..." Hacker News . Получено 29.06.2021 .
  27. ^ Литтл, Гэри Б. (1985). Внутри Apple IIc. Боуи, Мэриленд: Brady Communications Co. стр. 82. ISBN 0-89303-564-5. Получено 29.06.2021 .
  28. ^ "Быстрая сборка мусора". Call-APPLE : 40–45. Январь 1981.
  29. ^ Ворт, Дон (1984). Beneath Apple Pro DOS (PDF) (печатное издание марта 1985 г.). Чатсворт, Калифорния, США: Quality Software. стр. 2–6. ISBN 0-912985-05-4. Архивировано (PDF) из оригинала 2008-12-03 . Получено 2021-06-29 .
  30. ^ "Обзор Objective-C 2.0". Архивировано из оригинала 2010-07-24.
  31. ^ Сиракуза, Джон (2011-07-20). «Mac OS X 10.7 Lion: обзор Ars Technica».
  32. ^ ab "Apple заявляет, что производители приложений для Mac должны перейти на управление памятью ARC к маю". AppleInsider . 2015-02-20.
  33. ^ Сишон, Вальдемар (21 февраля 2015 г.). «App Store: программа Apple для сбора мусора». Heise.de . Проверено 30 марта 2015 г.
  34. ^ Silva, Precious (2014-11-18). "iOS 8 против Android 5.0 Lollipop: Apple убивает Google с помощью эффективности памяти". International Business Times . Архивировано из оригинала 2015-04-03 . Получено 2015-04-07 .
  35. ^ ab Napier, Rob; Kumar, Mugunth (2012-11-20). Программирование iOS 6, расширяющее границы. John Wiley & Sons . ISBN 978-1-11844997-4. Получено 30.03.2015 .
  36. ^ ab Cruz, José RC (2012-05-22). "Автоматический подсчет ссылок на iOS". Dr. Dobbs . Архивировано из оригинала 2020-05-16 . Получено 2015-03-30 .
  37. ^ Фу, Вэй; Хаузер, Карл (2005). "Структура для сбора мусора в реальном времени для встраиваемых систем". Труды семинара 2005 года по программному обеспечению и компиляторам для встраиваемых систем - SCOPES '05 . стр. 20–26. doi :10.1145/1140389.1140392. ISBN 1-59593207-0. S2CID  8635481.
  38. ^ ".NET nanoFramework".
  39. ^ Тене, Гил; Айенгар, Баладжи; Вольф, Майкл (2011). "C4: непрерывно действующий уплотняющий коллектор" (PDF) . ISMM '11: Труды международного симпозиума по управлению памятью . doi :10.1145/1993478. ISBN 978-1-45030263-0. Архивировано (PDF) из оригинала 2017-08-09.
  40. ^ Мазур, Нэнси (май 2004 г.). Сборка мусора во время компиляции для декларативного языка Mercury (PDF) (диссертация). Katholieke Universiteit Leuven . Архивировано (PDF) из оригинала 27.04.2014.
  41. ^ Хюльсберген, Лоренц; Винтерботтом, Фил (1998). "Очень параллельная сборка мусора по методу отметки и очистки без мелкозернистой синхронизации" (PDF) . Труды Первого международного симпозиума по управлению памятью - ISMM '98 . стр. 166–175. doi :10.1145/286860.286878. ISBN 1-58113114-3. S2CID  14399427. Архивировано (PDF) из оригинала 2008-05-13.
  42. ^ "Часто задаваемые вопросы по GC".
  43. ^ Либерман, Генри; Хьюитт, Карл (1983). «Сборщик мусора в реальном времени, основанный на времени жизни объектов». Сообщения ACM . 26 (6): 419–429. doi :10.1145/358141.358147. hdl : 1721.1/6335 . S2CID  14161480.
  44. ^ Бейкер, Генри Г. (1978). «Обработка списков в реальном времени на последовательном компьютере». Communications of the ACM . 21 (4): 280–294. doi :10.1145/359460.359470. hdl : 1721.1/41976 . S2CID  17661259.см. также описание
  45. ^ Макклоски; Бэкон; Ченг; Гроув (2008), Staccato: параллельный и параллельный сборщик мусора в реальном времени для многопроцессорных систем (PDF) , заархивировано (PDF) из оригинала 2014-03-11

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

Внешние ссылки

В Wikibook Memory Management есть страница на тему: Сборка мусора