쓰레기 수거(컴퓨터 과학)

Garbage collection (computer science)
이 기사는 메모리 관리의 가비지 컬렉션에 관한 것입니다. 솔리드 스테이트 드라이브의 가비지 컬렉션에 대해서는 가비지 컬렉션(SSD)을 참조하십시오.
리스프 아키텍처에서 가비지 수집 중지 및 복사:[1] 메모리는 작업 메모리와 사용 가능 메모리로 나뉘며, 전자에는 새 개체가 할당됩니다. 가득 차면(표시됨) 가비지 수집이 수행됩니다. 아직 사용 중인 모든 데이터 구조는 포인터 추적을 통해 위치를 파악하고 사용 가능한 메모리의 연속적인 위치에 복사됩니다.
그 후 작업 메모리 내용은 압축된 복사본에 유리하게 폐기되고 작업 메모리와 여유 메모리의 역할이 교환됩니다(그림).

컴퓨터 과학에서 GC(Garbage Collection)는 자동 메모리 관리의 한 형태입니다. 가비지 수집기는 프로그램에서 할당했지만 더 이상 참조되지 않는 메모리를 회수하려고 시도합니다. 이러한 메모리를 가비지(garbage)라고 합니다. 쓰레기 수거는 1959년경 미국의 컴퓨터 과학자 존 매카시에 의해 리스프의 수동 메모리 관리를 단순화하기 위해 발명되었습니다.[2]

가비지 컬렉션은 프로그래머가 메모리 시스템에 할당을 해제하고 반환할 개체와 시간을 지정하는 수동 메모리 관리를 수행하지 않도록 해줍니다.[3] 다른 유사한 기술에는 스택 할당, 영역 추론 및 메모리 소유 및 이들의 조합이 포함됩니다. 쓰레기 수거는 프로그램 전체 처리 시간의 상당 부분을 차지하여 결과적으로 성능에 영향을 미칠 수 있습니다.

네트워크 소켓, 데이터베이스 핸들, 윈도우, 파일 디스크립터 및 장치 디스크립터와 같은 메모리 이외의 리소스는 일반적으로 가비지 컬렉션이 아니라 다른 방법(예: 디스트럭터)에 의해 처리됩니다. 일부 이러한 방법은 메모리 할당을 해제하기도 합니다.

개요

많은 프로그래밍 언어는 언어 사양의 일부(예: RPL, Java, C#, D,[4] Go 및 대부분의 스크립팅 언어) 또는 실질적인 구현을 위해 효과적으로 가비지 컬렉션(예: 람다 미적분학과 같은 형식 언어)을 필요로 합니다.[citation needed] 이것들은 쓰레기 수집 언어라고 합니다. C 및 C++와 같은 다른 언어는 수동 메모리 관리를 위해 설계되었지만 가비지 컬렉션 구현이 가능합니다. Ada, Modula-3 및 C++/CLI와 같은 일부 언어에서는 수집된 개체와 수동으로 관리되는 개체에 대해 별도의 힙을 사용하여 가비지 수집과 수동 메모리 관리가 동일한 응용 프로그램에 공존할 수 있습니다. D와 같은 다른 것들은 가비지 컬렉션이지만 속도가 필요할 때 사용자가 객체를 수동으로 삭제하거나 가비지 컬렉션을 완전히 비활성화할 수 있습니다.

많은 언어들이 GC를 컴파일러와 런타임 시스템에 통합하지만, 자동 참조 카운팅(ARC)과 같은 사후 GC 시스템도 존재합니다. 이러한 사후 GC 시스템 중 일부는 재컴파일이 필요하지 않습니다. 사후 GC는 일반 GC와 구별하기 위해 쓰레기 수거라고 불리기도 합니다.[5]

이점

GC는 프로그래머가 수동으로 메모리 할당을 해제하는 것을 방지합니다. 이를 통해 다음과 같은 종류의 오류를 방지할 수 있습니다.

  • 메모리에 포인터가 있는 동안 메모리 조각이 풀리고 포인터 중 하나가 참조 해제될 때 발생하는 댕글링 포인터입니다. 그때까지 메모리가 다른 용도로 재할당되었을 수 있으며, 예측할 수 없는 결과가 발생했습니다.
  • 프로그램이 이미 확보한 메모리 영역을 다시 확보하려고 할 때 발생하는 이중 확보 버그입니다.
  • 특정 종류의 메모리가 누출되어 프로그램이 도달할 수 없는 개체가 사용한 메모리를 확보하지 못해 메모리가 고갈될 수 있습니다.[6]

단점들

GC는 컴퓨팅 리소스를 사용하여 확보할 메모리를 결정합니다. 따라서, 소스 코드에서 객체 수명에 수동으로 주석을 달지 않는 편의를 위한 패널티는 오버헤드이며, 이는 프로그램 성능을 손상시킬 수 있습니다.[7] 2005년에 발표된 동료 검토 논문에 따르면 GC는 이러한 오버헤드를 보상하고 이상화된 명시적 메모리 관리를 사용하여 동일한 프로그램만큼 빠른 속도로 수행하기 위해 5배의 메모리가 필요하다고 합니다. 그러나 프로파일러 아래에서 실행되는 프로그램에서 트레이스를 수집하여 구현된 오라클을 사용하여 할당 해제 호출을 삽입하여 생성된 프로그램과 비교되며 프로그램은 프로그램의 특정 실행 하나에만 적합합니다.[8] 메모리 계층 효과와 상호 작용하면 일상적인 테스트에서 예측하기 어렵거나 감지하기 어려운 환경에서 이러한 오버헤드를 견딜 수 없게 됩니다. 성능에 미치는 영향은 애플이 가장 원하는 기능임에도 불구하고 iOS에서 쓰레기 수거를 채택하지 않은 이유로 제시했습니다.[9]

쓰레기가 실제로 수거되는 순간을 예측할 수 없기 때문에 세션 전체에 걸쳐 스톨(메모리를 이동/사용 가능한 상태로 전환하기 위해 일시 중단)이 발생할 수 있습니다. 예측 불가능한 스톨은 실시간 환경, 트랜잭션 처리 또는 대화형 프로그램에서 허용되지 않을 수 있습니다. 증분, 동시 및 실시간 쓰레기 수집기는 다양한 절충을 통해 이러한 문제를 해결합니다.

전략들

추적

주 기사: 가비지 컬렉션 추적

추적 쓰레기 수집은 가장 일반적인 쓰레기 수집 유형이기 때문에 "쓰레기 수집"은 종종 참조 계산과 같은 다른 방법이 아니라 추적 쓰레기 수집을 의미합니다. 전체적인 전략은 어떤 객체가 어떤 객체에 도달할 수 있는지 추적하여 어떤 객체가 가비지가 되어야 하는지 결정하고, 나머지는 가비지로 간주하여 수집하는 것으로 구성됩니다. 그러나 구현에 사용되는 알고리즘은 복잡성과 성능 특성이 매우 다양한 많은 수가 있습니다.

기준계수

주 기사: 기준계수

참조 계산 가비지 컬렉션은 각 객체가 해당 가비지에 대한 참조 횟수를 카운트하는 곳입니다. 가비지는 기준 카운트가 0인 경우 식별됩니다. 개체에 대한 참조가 생성되면 개체의 참조 카운트가 증가하고 참조가 파괴되면 감소합니다. 카운트가 0이 되면 개체의 메모리가 회수됩니다.[10]

수동 메모리 관리와 마찬가지로, 가비지 컬렉션을 추적하는 것과는 달리 참조 카운트는 마지막 참조가 파괴되는 즉시 개체가 파괴되는 것을 보장하며, 일반적으로 CPU 캐시에 있거나 해방될 개체에 있는 메모리 또는 이러한 개체가 직접 가리키는 메모리에만 액세스합니다. 따라서 CPU 캐시 및 가상 메모리 작동에 큰 부정적인 부작용이 발생하지 않는 경향이 있습니다.

참조 계산에는 여러 가지 단점이 있습니다. 일반적으로 이는 보다 정교한 알고리즘에 의해 해결되거나 완화될 수 있습니다.

사이클
둘 이상의 개체가 서로를 참조하는 경우 상호 참조가 0이 되지 않으므로 둘 다 수집되지 않는 주기를 만들 수 있습니다. CPython의 것과 같은 참조 계수를 사용하는 일부 가비지 수집 시스템은 이 문제를 처리하기 위해 특정 주기 검출 알고리즘을 사용합니다.[11] 또 다른 전략은 사이클을 생성하는 "백포인터"에 약한 참조를 사용하는 것입니다. 참조 카운트에서 약한 참조는 추적 쓰레기 수집기 아래의 약한 참조와 유사합니다. 존재 여부에 따라 참조 개체의 참조 카운트가 증가하지 않는 특수 참조 개체입니다. 또한 약한 참조는 참조 대상이 쓰레기가 될 때 해당 대상에 대한 약한 참조는 널링 상태로 유지되도록 허용되는 것이 아니라 무효 참조와 같이 예측 가능한 값으로 변경된다는 점에서 안전합니다.
공간 오버헤드(참조 횟수)
참조 카운트에는 참조 카운트를 저장하기 위해 각 개체에 할당된 공간이 필요합니다. 카운트는 객체의 메모리에 인접하여 또는 다른 곳의 사이드 테이블에 저장될 수 있지만, 어느 경우에나, 모든 기준 카운트된 객체는 그 기준 카운트를 위해 추가적인 저장을 필요로 합니다. 이 작업에는 부호 없는 포인터 크기의 메모리 공간이 일반적으로 사용되며, 이는 각 개체에 대해 32비트 또는 64비트의 참조 카운트 스토리지가 할당되어야 함을 의미합니다. 일부 시스템에서, 참조 카운트를 객체의 메모리의 사용되지 않는 영역에 저장하기 위해 태깅된 포인터를 사용함으로써 이러한 오버헤드를 완화하는 것이 가능할 수 있습니다. 종종 아키텍처는 프로그램이 기본 포인터 크기에 저장될 수 있는 전체 범위의 메모리 주소에 액세스하는 것을 실제로 허용하지 않습니다. 주소에 있는 특정 수의 높은 비트는 무시되거나 0이어야 합니다. 객체가 특정 위치에 포인터를 안정적으로 가지고 있는 경우 기준 카운트는 포인터의 사용되지 않는 비트에 저장될 수 있습니다. 예를 들어, Object-C의 각 개체는 해당 개체의 메모리 시작 부분에 해당 클래스에 대한 포인터를 가지고 있으며, iOS 7을 사용하는 ARM64 아키텍처에서는 이 클래스 포인터의 19개의 사용되지 않은 비트가 개체의 참조 카운트를 저장하는 데 사용됩니다.[12][13]
속도 오버헤드(증가/감소)
순진한 구현에서 각 참조 할당과 범위를 벗어나는 각 참조는 종종 하나 이상의 참조 카운터를 수정해야 합니다. 그러나 기준이 외부 범위 변수에서 내부 범위 변수로 복사되어 내부 변수의 수명이 외부 범위 변수의 수명에 의해 제한되는 일반적인 경우에는 기준 증가를 제거할 수 있습니다. 외부 변수가 기준을 "소유"합니다. 프로그래밍 언어 C++에서 이 기술은 쉽게 구현되고 시연됩니다. const 참고 문헌 C++의 참조 카운팅은 일반적으로 "스마트 포인터"[14]를 사용하여 구현됩니다. 그의 생성자, 파괴자 및 할당 연산자는 참조를 관리합니다. 스마트 포인터는 기능을 참조하여 전달할 수 있으므로 새 스마트 포인터를 복사 구성할 필요가 없습니다(기능 입력 시 참조 횟수가 증가하고 종료 시 참조 횟수가 감소합니다). 대신 이 기능은 값싸게 생산되는 스마트 포인터에 대한 참조를 수신합니다. Deutsch-Bobrow 참조 카운트 방법은 대부분의 참조 카운트 업데이트가 실제로 로컬 변수에 저장된 참조에 의해 생성된다는 사실을 이용합니다. 이러한 참조를 무시하고 힙에서 참조만 계산하지만 참조 카운트가 0인 개체를 삭제하기 전에 시스템은 스택에 대한 검색으로 확인하고 해당 개체에 대한 다른 참조가 여전히 존재하지 않음을 등록해야 합니다. Levanoni와 Petrank가 도입한 업데이트 병합을 통해 카운터 업데이트에 대한 오버헤드를 더욱 크게 줄일 수 있습니다.[15][16] 지정된 실행 간격으로 여러 번 업데이트되는 포인터를 고려합니다. 그것은 먼저 물체를 가리킵니다. O1, 그 다음에 어떤 대상에 O2, 간격의 끝에서 어떤 물체를 가리킬 때까지 말입니다. On. 기준 계수 알고리즘은 일반적으로 실행됩니다. rc(O1)--, rc(O2)++, rc(O2)--, rc(O3)++, rc(O3)--, ..., rc(On)++. 그러나 이러한 업데이트는 대부분 중복됩니다. 간격이 끝날 때 기준 카운트를 적절하게 평가하려면 수행하기에 충분합니다. rc(O1)-- 그리고. rc(On)++. Levanoni와 Petrank는 일반적인 Java 벤치마크에서 카운터 업데이트의 99% 이상을 제거하는 것으로 측정했습니다.
원자성이 필요합니다.
다중 스레드 환경에서 사용되는 경우 이러한 수정(증강 및 감소)은 적어도 여러 스레드 간에 공유되거나 잠재적으로 공유되는 개체에 대해 비교 및 스왑과 같은 원자적 작업이어야 할 수 있습니다. 원자 연산은 멀티프로세서에서 비용이 많이 들고 소프트웨어 알고리즘으로 에뮬레이션해야 하는 경우 훨씬 더 비쌉니다. 스레드별 또는 CPU별 참조 카운트를 추가하고 로컬 참조 카운트가 0이 되거나 더 이상 0이 아닐 때에만 글로벌 참조 카운트에 액세스하여 이 문제를 피할 수 있습니다(또는 참조 카운트의 이진 트리를 사용하여). 또는 글로벌 참조 카운트가 전혀 없는 대신 결정론적 파괴를 포기하기도 합니다. 그러나 이것은 상당한 메모리 오버헤드를 추가하므로 특수한 경우에만 유용한 경향이 있습니다(예를 들어 리눅스 커널 모듈의 참조 카운트에 사용됨). Levanoni와 Petrank에[15][16] 의한 업데이트 병합을 사용하여 쓰기 장벽에서 모든 원자 작동을 제거할 수 있습니다. 카운터는 프로그램 실행 과정에서 프로그램 스레드에 의해 업데이트되지 않습니다. 이들은 동기화 없이 단일 추가 스레드로 실행되는 수집기에 의해서만 수정됩니다. 이 방법은 병렬 프로그램 및 동시 참조 계수 수집기에 대한 stop-the-world 메커니즘으로 사용할 수 있습니다.
실시간 아님
참조 카운트의 순진한 구현은 일반적으로 실시간 동작을 제공하지 않습니다. 왜냐하면 어떤 포인터 할당도 스레드가 다른 작업을 수행할 수 없는 동안 총 할당된 메모리 크기로만 제한된 많은 개체를 재귀적으로 해방시킬 수 있기 때문입니다. 추가 오버헤드 비용을 지불하고 참조되지 않은 개체의 자유를 다른 스레드에 위임함으로써 이 문제를 방지할 수 있습니다.

이스케이프 분석

주 기사: 이스케이프 분석

이스케이프 분석은 힙 할당을 스택 할당으로 변환할 수 있는 컴파일 타임 기법으로, 수행해야 할 가비지 수집의 양을 줄일 수 있습니다. 이 분석은 함수 내부에 할당된 개체가 함수 외부에서 액세스할 수 있는지 여부를 결정합니다. 함수-로컬 할당이 다른 함수 또는 스레드에 액세스할 수 있는 것으로 확인되면 할당은 "탈출"이라고 하며 스택에서 수행할 수 없습니다. 그렇지 않으면 객체가 스택에 직접 할당되고 함수가 반환될 때 해제되어 힙 및 관련 메모리 관리 비용을 우회할 수 있습니다.[17]

유용성

일반적으로 상위 프로그래밍 언어는 가비지 컬렉션을 표준 기능으로 가질 가능성이 더 높습니다. 가비지 컬렉션에 내장되지 않은 일부 언어에서는 C 및 C++용 Boehm 가비지 컬렉터와 마찬가지로 라이브러리를 통해 추가할 수 있습니다.

ML, Haskell, APL과 같은 대부분의 기능적인 프로그래밍 언어에는 가비지 컬렉션이 내장되어 있습니다. 리스프는 특히 최초의 기능적 프로그래밍 언어이자 가비지 컬렉션을 도입한 최초의 언어로 주목받고 있습니다.[18]

루비와 줄리아와 같은 다른 동적 언어(둘 다 참조 계수를 사용하는 [19]버전 5.3 이전의 펄 5나 PHP는 아님), 자바스크립트와 ECMA스크립트도 GC를 사용하는 경향이 있습니다. Smalltalk, RPL, Java와 같은 객체 지향 프로그래밍 언어는 보통 통합 가비지 컬렉션을 제공합니다. 눈에 띄는 예외는 파괴자가 있는 C++와 델파이입니다.

기본의

BASIC과 Logo는 프로그래머에게 메모리 관리 세부 정보를 부담시키지 않기 위해 문자열이나 목록과 같은 가변 길이의 데이터 유형에 가비지 컬렉션을 사용하는 경우가 많았습니다. Altair 8800에서는 문자열 변수가 많고 문자열 공간이 적은 프로그램은 가비지 컬렉션으로 인해 긴 일시 중지가 발생할 수 있습니다.[20] 마찬가지로 Applesoft BASIC 인터프리터의 가비지 컬렉션 알고리즘은 높은 메모리를 향해 압축하기 위해 가장 높은 주소를 가진 문자열에 대해 문자열 디스크립터를 반복적으로 스캔하여 2 성능을[21] 발생시키고 몇 초에서 몇 분 사이의 임의의 장소에서 일시 중지합니다.[22] Randy Wigginton의 Applesoft BASIC의 대체 쓰레기 수집기는 더미 위의 모든 통로에서 문자열 그룹을 식별하여 수집 시간을 획기적으로 줄입니다.[23] 기본의.1983년 ProDOS와 함께 출시된 SYSTEM은 몇 배 더 빠른 BASIC용 윈도우 가비지 콜렉터를 제공합니다.[24]

목적-C

2007년 OS X 10.5가 출시되면서 Object-C는 전통적으로 쓰레기 수거가 없었지만, 애플은 자체 개발한 런타임 수집기를 사용하여 Object-C 2.0을 위한 쓰레기 수거를 도입했습니다.[25] 그러나 2012년 OS X 10.8이 출시되면서 쓰레기 수거는 OS X 10.7과 함께 도입된 LLVM의 자동 참조 카운터(ARC)에 유리하게 사용되지 않게 되었습니다.[26] 또한 2015년 5월부터 애플은 앱스토어에서 새로운 OS X 애플리케이션에 대한 쓰레기 수거 사용을 금지하고 있습니다.[27][28] iOS의 경우 애플리케이션 응답성과 성능의 문제로 인해 가비지 컬렉션이 도입된 [9][29]적이 없으며 대신에 iOS는 ARC를 사용합니다.[30][31]

제한된 환경

제한된 자원의 사용을 매우 엄격하게 통제해야 하는 일반적인 필요성 때문에 내장형 또는 실시간 시스템에서는 쓰레기 수집이 거의 사용되지 않습니다. 그러나 많은 제한된 환경과 호환되는 쓰레기 수거기가 개발되었습니다.[32] 마이크로소프트.NET Micro Framework, .NET nanoFramework와[33] Java Platform, Micro Edition은 큰 사촌들과 마찬가지로 쓰레기 수거를 포함하는 내장 소프트웨어 플랫폼입니다.

자바

자바 JDK에서 사용할 수 있는 가비지 콜렉터는 다음과 같습니다.

컴파일 시간 사용

컴파일 시간 가비지 컬렉션은 컴파일 중에 알려진 불변량을 기반으로 메모리를 재사용하고 회수할 수 있도록 하는 정적 분석의 한 형태입니다.

이러한 형태의 쓰레기 수거는 Mercury 프로그래밍 언어로 연구되어 왔으며,[35] 2011년 LLVM의 자동 참조 카운터(ARC)가 애플의 생태계(iOS와 OS X)에 도입되면서 더 많은 사용이 가능해졌습니다.[30][31][27]

실시간 시스템

예를 들어, Henry Baker와 Henry Lieberman에 의해 증분, 동시 및 실시간 쓰레기 수집기가 개발되었습니다.[36][37][38]

Baker의 알고리즘에서 할당은 단일 메모리 영역의 절반에서 수행됩니다. 절반이 차면 살아있는 개체를 나머지 절반으로 이동하고 나머지 개체는 암시적으로 할당 해제되는 가비지 컬렉션이 수행됩니다. 실행 중인 프로그램('돌연변이체')은 참조하는 모든 개체가 올바른 절반인지 확인해야 하며, 이동하지 않는 경우에는 모든 개체를 찾는 백그라운드 작업을 수행해야 합니다.[39]

세대별 쓰레기 수집 계획은 대부분의 물체가 일찍 죽는다는 경험적 관찰을 기반으로 합니다. 세대별 쓰레기 수집에서는 2개 이상의 할당 구역(세대)이 유지되며, 이 구역은 물체의 나이에 따라 분리되어 있습니다. 정기적으로 수집되는 "젊은" 세대에서 새 개체가 생성되고, 한 세대가 가득 차면 이전 지역에서 여전히 참조되는 개체가 다음으로 오래된 세대로 복사됩니다. 때때로 전체 검색이 수행됩니다.

일부 고급 언어 컴퓨터 아키텍처에는 실시간 가비지 수집을 위한 하드웨어 지원이 포함됩니다.

실시간 쓰레기 수집기의 대부분의 구현은 추적을 사용합니다.[citation needed] 이러한 실시간 쓰레기 수거기는 실시간 운영 체제와 함께 사용할 때 어려운 실시간 제약 조건을 충족합니다.[40]

참고 항목

참고문헌

  1. ^ Abelson, Harold; Sussman, Gerald Jay; Sussman, Julie (2016). Structure and Interpretation of Computer Programs (PDF) (2nd ed.). Cambridge, Massachusetts, USA: MIT Press. pp. 734–736.
  2. ^ McCarthy, John (1960). "Recursive functions of symbolic expressions and their computation by machine, Part I". Communications of the ACM. 3 (4): 184–195. doi:10.1145/367177.367199. S2CID 1489409. Retrieved 2009-05-29.
  3. ^ "What is garbage collection (GC) in programming?". SearchStorage. Retrieved 2022-10-17.
  4. ^ "Overview – D Programming Language". dlang.org. Digital Mars. Retrieved 2014-07-29.
  5. ^ "Garbage Collection - D Programming Language". dlang.org. Retrieved 2022-10-17.
  6. ^ Microsoft. "Fundamentals of garbage collection Microsoft Learn". Retrieved 2023-03-29.
  7. ^ Zorn, Benjamin (1993-01-22). "The Measured Cost of Conservative Garbage Collection". Software: Practice and Experience. Department of Computer Science, University of Colorado Boulder. 23 (7): 733–756. CiteSeerX 10.1.1.14.1816. doi:10.1002/spe.4380230704. S2CID 16182444.
  8. ^ Hertz, Matthew; Berger, Emery D. (2005). "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" (PDF). Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications - OOPSLA '05. pp. 313–326. doi:10.1145/1094811.1094836. ISBN 1-59593031-0. S2CID 6570650. Archived (PDF) from the original on 2012-04-02. Retrieved 2015-03-15.
  9. ^ a b "Developer Tools Kickoff – session 300" (PDF). WWDC 2011. Apple, Inc. 2011-06-24. Retrieved 2015-03-27.
  10. ^ Microsoft. "Reference Counting Garbage Collection". Retrieved 2023-03-29.
  11. ^ "Reference Counts". Extending and Embedding the Python Interpreter. 2008-02-21. Retrieved 2014-05-22.
  12. ^ Ash, Mike. "Friday Q&A 2013-09-27: ARM64 and You". mikeash.com. Retrieved 2014-04-27.
  13. ^ "Hamster Emporium: [objc explain]: Non-pointer isa". Sealiesoftware.com. 2013-09-24. Retrieved 2014-04-27.
  14. ^ Pibinger, Roland (2005-05-03) [2005-04-17]. "RAII, Dynamic Objects, and Factories in C++".
  15. ^ a b Levanoni, Yossi; Petrank, Erez (2001). "An on-the-fly reference-counting garbage collector for java". Proceedings of the 16th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications. OOPSLA 2001. pp. 367–380. doi:10.1145/504282.504309.
  16. ^ a b Levanoni, Yossi; Petrank, Erez (2006). "An on-the-fly reference-counting garbage collector for java". ACM Trans. Program. Lang. Syst. 28: 31–69. CiteSeerX 10.1.1.15.9106. doi:10.1145/1111596.1111597. S2CID 14777709.
  17. ^ Salagnac, Guillaume; Yovine, Sergio; Garbervetsky, Diego (2005-05-24). "Fast Escape Analysis for Region-based Memory Management". Electronic Notes in Theoretical Computer Science. 131: 99–110. doi:10.1016/j.entcs.2005.01.026.
  18. ^ Chisnall, David (2011-01-12). Influential Programming Languages, Part 4: Lisp.
  19. ^ "PHP: Performance Considerations". php.net. Retrieved 2015-01-14.
  20. ^ "Altair 8800 Basic 4.1 Reference Manual" (PDF). The Vintage Technology Digital Archive. April 1977. p. 108. Archived (PDF) from the original on 2021-06-29. Retrieved 2021-06-29.
  21. ^ "I did some work to speed up string garbage collection under Applesoft..." Hacker News. Retrieved 2021-06-29.
  22. ^ Little, Gary B. (1985). Inside the Apple IIc. Bowie, Md.: Brady Communications Co. p. 82. ISBN 0-89303-564-5. Retrieved 2021-06-29.
  23. ^ "Fast Garbage Collection". Call-A.P.P.L.E.: 40–45. January 1981.
  24. ^ Worth, Don (1984). Beneath Apple Pro DOS (PDF) (March 1985 printing ed.). Chatsworth, California, USA: Quality Software. pp. 2–6. ISBN 0-912985-05-4. Archived (PDF) from the original on 2008-12-03. Retrieved 2021-06-29.
  25. ^ "Objective-C 2.0 Overview". Archived from the original on 2010-07-24.
  26. ^ Siracusa, John (2011-07-20). "Mac OS X 10.7 Lion: the Ars Technica review".
  27. ^ a b "Apple says Mac app makers must transition to ARC memory management by May". AppleInsider. 2015-02-20.
  28. ^ Cichon, Waldemar (2015-02-21). "App Store: Apple entfernt Programme mit Garbage Collection". Heise.de. Retrieved 2015-03-30.
  29. ^ Silva, Precious (2014-11-18). "iOS 8 vs Android 5.0 Lollipop: Apple Kills Google with Memory Efficiency". International Business Times. Retrieved 2015-04-07.
  30. ^ a b Napier, Rob; Kumar, Mugunth (2012-11-20). iOS 6 Programming Pushing the Limit. John Wiley & Sons. ISBN 978-1-11844997-4. Retrieved 2015-03-30.
  31. ^ a b Cruz, José R. C. (2012-05-22). "Automatic Reference Counting on iOS". Dr. Dobbs. Archived from the original on 2020-05-16. Retrieved 2015-03-30.
  32. ^ Fu, Wei; Hauser, Carl (2005). "A real-time garbage collection framework for embedded systems". Proceedings of the 2005 Workshop on Software and Compilers for Embedded Systems - SCOPES '05. pp. 20–26. doi:10.1145/1140389.1140392. ISBN 1-59593207-0. S2CID 8635481.
  33. ^ ".NET nanoFramework".
  34. ^ Tene, Gil; Iyengar, Balaji; Wolf, Michael (2011). "C4: the continuously concurrent compacting collector" (PDF). ISMM '11: Proceedings of the international symposium on Memory management. doi:10.1145/1993478. ISBN 978-1-45030263-0. Archived (PDF) from the original on 2017-08-09.
  35. ^ Mazur, Nancy (May 2004). Compile-time garbage collection for the declarative language Mercury (PDF) (Thesis). Katholieke Universiteit Leuven. Archived (PDF) from the original on 2014-04-27.
  36. ^ Huelsbergen, Lorenz; Winterbottom, Phil (1998). "Very concurrent mark-&-sweep garbage collection without fine-grain synchronization" (PDF). Proceedings of the First International Symposium on Memory Management - ISMM '98. pp. 166–175. doi:10.1145/286860.286878. ISBN 1-58113114-3. S2CID 14399427. Archived (PDF) from the original on 2008-05-13.
  37. ^ "GC FAQ".
  38. ^ Lieberman, Henry; Hewitt, Carl (1983). "A real-time garbage collector based on the lifetimes of objects". Communications of the ACM. 26 (6): 419–429. doi:10.1145/358141.358147. hdl:1721.1/6335. S2CID 14161480.
  39. ^ Baker, Henry G. (1978). "List processing in real time on a serial computer". Communications of the ACM. 21 (4): 280–294. doi:10.1145/359460.359470. hdl:1721.1/41976. S2CID 17661259. 참고 항목설명
  40. ^ McCloskey; Bacon; Cheng; Grove (2008), Staccato: A Parallel and Concurrent Real-time Compacting Garbage Collector for Multiprocessors (PDF), archived (PDF) from the original on 2014-03-11

더보기

외부 링크

Wikibook Memory Management(위키북 메모리 관리)에는 Garbage Collection(가비지 컬렉션)이라는 주제의 페이지가 있습니다.