stringtranslate.com

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

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

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

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

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

Обзор

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

Хотя многие языки интегрируют GC в свои компиляторы и системы выполнения , также существуют системы post-hoc GC, такие как автоматический подсчет ссылок (ARC). Некоторые из этих систем post-hoc GC не требуют перекомпиляции. [5]

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

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

Недостатки

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

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

Стратегии

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

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

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

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

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

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

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

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

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

Доступность

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

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

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

БАЗОВЫЙ

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

Цель-C

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

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

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

Джава

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

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

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

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

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

Инкрементные, параллельные сборщики мусора и сборщики мусора в реальном времени были разработаны, например, Генри Бейкером и Генри Либерманом . [37] [38] [39]

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

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

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

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

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

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

  1. ^ Абельсон, Гарольд; Сассман, Джеральд Джей; Сассман, Джули (2016). Структура и интерпретация компьютерных программ (PDF) (2-е изд.). Кембридж, Массачусетс, США: MIT Press . стр. 734–736.
  2. ^ Маккарти, Джон (1960). «Рекурсивные функции символьных выражений и их машинное вычисление, Часть I». Коммуникации АКМ . 3 (4): 184–195. дои : 10.1145/367177.367199 . S2CID  1489409 . Проверено 29 мая 2009 г.
  3. ^ «Что такое сборка мусора (GC) в программировании?». ПоискХранилища . Проверено 17 октября 2022 г.
  4. ^ «Обзор - Язык программирования D» . dlang.org . Цифровой Марс . Проверено 29 июля 2014 г.
  5. ^ «Сборка мусора — язык программирования D» . dlang.org . Проверено 17 октября 2022 г.
  6. ^ «Сбор мусора». rebelsky.cs.grinnell.edu . Проверено 13 января 2024 г.
  7. ^ Майкрософт . «Основы сборки мусора | Microsoft Learn» . Проверено 29 марта 2023 г.
  8. ^ Зорн, Бенджамин (22 января 1993 г.). «Оценочная стоимость консервативного сбора мусора». Программное обеспечение: практика и опыт . Кафедра компьютерных наук Университета Колорадо в Боулдере . 23 (7): 733–756. CiteSeerX 10.1.1.14.1816 . дои : 10.1002/спе.4380230704. S2CID  16182444. 
  9. ^ Герц, Мэтью; Бергер, Эмери Д. (2005). «Количественная оценка производительности сборки мусора по сравнению с явным управлением памятью» (PDF) . Материалы 20-й ежегодной конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям — OOPSLA '05 . стр. 313–326. дои : 10.1145/1094811.1094836. ISBN 1-59593031-0. S2CID  6570650. Архивировано (PDF) из оригинала 2 апреля 2012 г. Проверено 15 марта 2015 г.
  10. ^ ab «Начало работы с инструментами разработчика – сеанс 300» (PDF) . WWDC 2011 . Apple, Inc. 24 июня 2011 г. Архивировано из оригинала (PDF) 4 сентября 2023 г. Проверено 27 марта 2015 г.
  11. ^ Майкрософт . «Сборка мусора с подсчетом ссылок» . Проверено 29 марта 2023 г.
  12. ^ «Счетчик ссылок». Расширение и встраивание интерпретатора Python . 21 февраля 2008 г. Проверено 22 мая 2014 г.
  13. ^ Эш, Майк. «Пятничные вопросы и ответы 27 сентября 2013 г.: ARM64 и вы». mikeash.com . Проверено 27 апреля 2014 г.
  14. ^ "Hamster Emporium: [объяснение объекта]: isa без указателя" . Sealiesoftware.com. 24 сентября 2013 г. Проверено 27 апреля 2014 г.
  15. ^ Пибингер, Роланд (3 мая 2005 г.) [17 апреля 2005 г.]. «RAII, динамические объекты и фабрики в C++».
  16. ^ аб Леванони, Йоси; Петранк, Эрез (2001). «Сборщик мусора с подсчетом ссылок на лету для Java». Материалы 16-й конференции ACM SIGPLAN по объектно-ориентированному программированию, системам, языкам и приложениям . OOPSLA 2001. стр. 367–380. дои : 10.1145/504282.504309.
  17. ^ аб Леванони, Йоси; Петранк, Эрез (2006). «Сборщик мусора с подсчетом ссылок на лету для Java». АКМ Транс. Программа. Ланг. Сист . 28 : 31–69. CiteSeerX 10.1.1.15.9106 . дои : 10.1145/1111596.1111597. S2CID  14777709. 
  18. ^ Саланьяк, Гийом; Йовине, Серхио; Гарбервецкий, Диего (24 мая 2005 г.). «Анализ быстрого выхода для управления памятью на основе регионов». Электронные заметки по теоретической информатике . 131 : 99–110. дои : 10.1016/j.entcs.2005.01.026 .
  19. ^ Чисналл, Дэвид (12 января 2011 г.). Влиятельные языки программирования, часть 4: Лисп.
  20. ^ «PHP: соображения производительности» . php.net . Проверено 14 января 2015 г.
  21. ^ «Справочное руководство Altair 8800 Basic 4.1» (PDF) . Цифровой архив винтажных технологий . Апрель 1977 г. с. 108. Архивировано (PDF) из оригинала 29 июня 2021 г. Проверено 29 июня 2021 г.
  22. ^ «Я проделал некоторую работу, чтобы ускорить сбор строкового мусора в Applesoft…» Hacker News . Проверено 29 июня 2021 г.
  23. ^ Литтл, Гэри Б. (1985). Внутри Apple IIc. Боуи, Мэриленд: Brady Communications Co. p. 82. ИСБН 0-89303-564-5. Проверено 29 июня 2021 г.
  24. ^ «Быстрая сборка мусора». Звонок-ЯБЛОКО : 40–45. Январь 1981 года.
  25. ^ Стоит, Дон (1984). Под Apple Pro DOS (PDF) (печатная версия, март 1985 г.). Чатсворт, Калифорния, США: Качественное программное обеспечение. стр. 2–6. ISBN 0-912985-05-4. Архивировано (PDF) из оригинала 3 декабря 2008 г. Проверено 29 июня 2021 г.
  26. ^ «Обзор Objective-C 2.0» . Архивировано из оригинала 24 июля 2010 г.
  27. ^ Сиракузы, Джон (20 июля 2011 г.). «Mac OS X 10.7 Lion: обзор Ars Technica».
  28. ^ ab «Apple заявляет, что производители приложений для Mac должны перейти на управление памятью ARC к маю». AppleInsider . 20 февраля 2015 г.
  29. ^ Сишон, Вальдемар (21 февраля 2015 г.). «App Store: программа Apple для сбора мусора». Heise.de . Проверено 30 марта 2015 г.
  30. ^ Сильва, Драгоценный (18 ноября 2014 г.). «iOS 8 против Android 5.0 Lollipop: Apple убивает Google эффективностью памяти». Интернэшнл Бизнес Таймс . Архивировано из оригинала 3 апреля 2015 г. Проверено 7 апреля 2015 г.
  31. ^ Аб Напье, Роб; Кумар, Мугунт (20 ноября 2012 г.). Программирование iOS 6, расширяющее границы. Джон Уайли и сыновья . ISBN 978-1-11844997-4. Проверено 30 марта 2015 г.
  32. ^ Аб Круз, Хосе RC (22 мая 2012 г.). «Автоматический подсчет ссылок на iOS». Доктор Доббс . Архивировано из оригинала 16 мая 2020 г. Проверено 30 марта 2015 г.
  33. ^ Фу, Вэй; Хаузер, Карл (2005). «Среда сбора мусора в реальном времени для встроенных систем». Материалы семинара 2005 г. по программному обеспечению и компиляторам для встраиваемых систем - SCOPES '05 . стр. 20–26. дои : 10.1145/1140389.1140392. ISBN 1-59593207-0. S2CID  8635481.
  34. ^ «.NET nanoFramework».
  35. ^ Тене, Гил; Айенгар, Баладжи; Вольф, Майкл (2011). «C4: коллектор непрерывного уплотнения» (PDF) . ISMM '11: Материалы международного симпозиума по управлению памятью . дои : 10.1145/1993478. ISBN 978-1-45030263-0. Архивировано (PDF) из оригинала 9 августа 2017 г.
  36. ^ Мазур, Нэнси (май 2004 г.). Сборка мусора во время компиляции для декларативного языка Mercury (PDF) (Диссертация). Католический университет Левена . Архивировано (PDF) из оригинала 27 апреля 2014 г.
  37. ^ Хюльсберген, Лоренц; Уинтерботтом, Фил (1998). «Очень параллельная сборка мусора с пометкой и очисткой без детальной синхронизации» (PDF) . Материалы Первого международного симпозиума по управлению памятью - ISMM '98 . стр. 166–175. дои : 10.1145/286860.286878. ISBN 1-58113114-3. S2CID  14399427. Архивировано (PDF) из оригинала 13 мая 2008 г.
  38. ^ «Часто задаваемые вопросы по GC» .
  39. ^ Либерман, Генри; Хьюитт, Карл (1983). «Сборщик мусора в реальном времени, основанный на времени жизни объектов». Коммуникации АКМ . 26 (6): 419–429. дои : 10.1145/358141.358147. hdl : 1721.1/6335 . S2CID  14161480.
  40. ^ Бейкер, Генри Г. (1978). «Обработка списков в реальном времени на последовательном компьютере». Коммуникации АКМ . 21 (4): 280–294. дои : 10.1145/359460.359470. hdl : 1721.1/41976 . S2CID  17661259.см. также описание
  41. ^ Макклоски; Бекон; Ченг; Grove (2008), Staccato: параллельный и параллельный сборщик мусора с уплотнением в реальном времени для мультипроцессоров (PDF) , заархивировано (PDF) из оригинала 11 марта 2014 г.

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

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

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