~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ FC9141FBAA2F8909CFA97B180E7764E8__1716478860 ✰
Заголовок документа оригинал.:
✰ Garbage collection (computer science) - Wikipedia ✰
Заголовок документа перевод.:
✰ Сбор мусора (информатика) — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/Garbage_collection_(computer_science) ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/fc/e8/fc9141fbaa2f8909cfa97b180e7764e8.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/fc/e8/fc9141fbaa2f8909cfa97b180e7764e8__translat.html ✰
Дата и время сохранения документа:
✰ 16.06.2024 09:30:13 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 23 May 2024, at 18:41 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.)https://arc.ask3.ruОтветы на вопросы (Сервис ответов на вопросы, в основном, научной направленности)https://ask3.ru/answer2questionТоварный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collationПартнерыhttps://comrades.ask3.ru


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

Сбор мусора (информатика) — Википедия Jump to content

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

Из Википедии, бесплатной энциклопедии

Сборка мусора с остановкой и копированием в архитектуре 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]

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

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

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]

Objective-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. ^ Перейти обратно: а б «Начало работы с инструментами разработчика – сеанс 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. ^ Перейти обратно: а б «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. ^ Перейти обратно: а б Круз, Хосе Р.К. (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 г.

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

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

Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: FC9141FBAA2F8909CFA97B180E7764E8__1716478860
URL1:https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Заголовок, (Title) документа по адресу, URL1:
Garbage collection (computer science) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)