Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

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

Принципы [ править ]

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

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

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

Преимущества [ править ]

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

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

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

Недостатки [ править ]

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

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

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

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

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

Стратегии [ править ]

Отслеживание [ править ]

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

Подсчет ссылок [ править ]

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

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

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

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

Анализ побега [ править ]

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

Сердцебиение и отметка времени [ править ]

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

Доступность [ править ]

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

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

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

ОСНОВНОЙ [ править ]

Исторически сложилось так, что языки, предназначенные для начинающих, такие как BASIC и Logo , часто использовали сборку мусора для типов данных переменной длины, размещенных в куче, таких как строки и списки, чтобы не обременять программистов ручным управлением памятью. На ранних микрокомпьютерах с их ограниченной памятью и медленными процессорами сборка мусора BASIC часто могла вызывать явно случайные, необъяснимые паузы в процессе работы программы.

Некоторые интерпретаторы BASIC, такие как Applesoft BASIC в семействе Apple II , неоднократно сканировали строковые дескрипторы для строки с наивысшим адресом, чтобы сжать ее в сторону верхней памяти, что приводило к производительности O (n 2 ) , что могло привести к увеличению продолжительности приостанавливает выполнение программ с интенсивным использованием строк. Заменяющий сборщик мусора для Applesoft BASIC, опубликованный в Call-APPLE (январь 1981, страницы 40–45, Randy Wigginton ), выявлял группу строк при каждом проходе по куче, что резко сокращало время сбора. BASIC.System, выпущенная вместе с ProDOS в 1983 году предоставил оконный сборщик мусора для BASIC, который сократил большинство сборок до долей секунды.

Objective-C [ править ]

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

Ограниченная среда [ править ]

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

Java [ править ]

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

  • G1
  • Параллельный
  • Сборщик параллельных меток (CMS)
  • Серийный
  • C4 (непрерывно параллельный уплотнительный коллектор) [25]
  • Шенандоа
  • ZGC

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

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

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

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

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

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

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

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

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

См. Также [ править ]

  • Деструктор (компьютерное программирование)
  • Международный симпозиум по управлению памятью
  • Управление памятью
  • Устранение мертвого кода
  • Умный указатель
  • Сжатие виртуальной памяти

Ссылки [ править ]

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

Дальнейшее чтение [ править ]

  • Джонс, Ричард; Хоскинг, Антоний; Мосс, Дж. Элиот Б. (16 августа 2011 г.). Справочник по сборке мусора: искусство автоматического управления памятью . Прикладные алгоритмы CRC и серии структур данных. Чапмен и Холл / CRC Press / Taylor & Francis Ltd . ISBN 978-1-4200-8279-1. (511 страниц)
  • Джонс, Ричард; Линс, Рафаэль (1996-07-12). Сборка мусора: алгоритмы автоматического управления динамической памятью (1-е изд.). Вайли . ISBN 978-0-47194148-4. (404 стр.)
  • Шорр, Герберт; Уэйт, Уильям М. (август 1967). «Эффективная машинно-независимая процедура сборки мусора в различных структурах списков» (PDF) . Коммуникации ACM . 10 (8): 501–506. DOI : 10.1145 / 363534.363554 . S2CID  5684388 .
  • Уилсон, Пол Р. (1992). «Однопроцессорные методы сборки мусора». Труды международного семинара по управлению памятью (IWMM 92) . Конспект лекций по информатике. Springer-Verlag . 637 : 1–42. CiteSeerX  10.1.1.47.2438 . DOI : 10.1007 / bfb0017182 . ISBN 3-540-55940-Х.
  • Уилсон, Пол Р .; Johnstone, Mark S .; Нили, Майкл; Болес, Дэвид (1995). «Динамическое распределение памяти: обзор и критический обзор». Труды международного семинара по управлению памятью (IWMM 95) . Конспект лекций по информатике (1-е изд.). 986 : 1–116. CiteSeerX  10.1.1.47.275 . DOI : 10.1007 / 3-540-60368-9_19 . ISBN 978-3-540-60368-9.

Внешние ссылки [ править ]

  • Справочник по управлению памятью
  • Самые основы сборки мусора
  • Настройка сборки мусора виртуальной машины Java SE 6 HotSpot ™
  • TinyGC - независимая реализация API BoehmGC
  • Консервативная реализация сборки мусора для языка C
  • MeixnerGC - инкрементальный сборщик мусора для C ++ с использованием интеллектуальных указателей