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

3. 작동 원리

가비지 컬렉션은 프로그램 실행 중 메모리 관리를 자동화하는 기술이다. 기존 메모리 관리 방식에서는 프로그래머가 프로그램 내에서 메모리 할당 및 해제를 직접 관리해야 했다. 가비지 컬렉션을 사용하면 메모리 확보는 프로그래머가 명시적으로 수행하지만, 해제는 가비지 컬렉터가 자동으로 처리한다. 가비지 컬렉터는 프로그램이 더 이상 사용하지 않는 메모리, 즉 도달 불가능한 메모리를 식별하여 회수한다. 이때 스택이나 변수 테이블 등으로부터의 참조를 추적하여 메모리 접근 가능성을 판단한다.

가비지 컬렉션은 프로그래밍 언어, 언어 처리 시스템, 프레임워크에 내장되거나 외부 라이브러리 형태로 제공될 수 있다. 자바는 언어 사양에 가비지 컬렉션이 표준적으로 내장되어 있지만, C 언어나 C++(C++)에서는 Boehm GC/Boehm garbage collector^영어와 같은 라이브러리나 스마트 포인터를 통해 가비지 컬렉션을 구현할 수 있다.

가비지 컬렉션은 프로그램의 주된 동작과는 별개로 수행되는 작업이므로, 프로그램 성능에 미치는 영향을 최소화하는 것이 중요하다. 데스크톱 애플리케이션에서는 짧은 응답 시간을 위해 가비지 컬렉션으로 인한 프로그램 정지 시간을 줄이는 것이 중요하며, 서버 애플리케이션에서는 처리량을 높이는 것이 중요하다. 임베디드 시스템에서는 리소스 소비를 줄이는 것이 중요하며, 실시간 시스템에서는 프로그램 동작 시간의 편차를 최소화해야 한다. 이러한 다양한 요구 사항을 충족하기 위해 여러 가비지 컬렉션 알고리즘이 개발되었다.

대표적인 가비지 컬렉션 알고리즘은 다음과 같다.

• 참조 카운트: 객체를 참조하는 포인터 수를 세어 0이 되면 해제하는 방식이다. 하지만 순환 참조 문제를 해결하지 못하고, 해제가 집중될 경우 정지 시간이 길어질 수 있다.
• 마크 앤 스위프: 객체에서 다른 객체로의 참조를 따라가 도달할 수 없는 객체를 제거하는 방식이다.
• 복사 GC: 현재 사용 중인 메모리 영역 외에 동일한 크기의 메모리 영역을 추가로 준비하여, 가비지 컬렉션 시점에 유효한 객체만 다른 영역으로 복사하는 방식이다. 이 방식은 메모리 공간을 2배로 사용하고 객체의 주소가 변경될 수 있지만, 가비지 컬렉션과 메모리 압축을 동시에 수행할 수 있다는 장점이 있다.

• 댕글링 포인터: 메모리가 해제되었지만 해당 메모리를 가리키는 포인터가 남아있어 발생하는 오류이다. 이 포인터가 역참조될 경우 예측 불가능한 결과를 초래할 수 있다.^[7]
• 이중 해제 버그: 이미 해제된 메모리 영역을 다시 해제하려 할 때 발생하는 오류이다.
• 메모리 누수: 프로그램이 더 이상 사용하지 않는 객체의 메모리를 해제하지 못해 메모리 고갈로 이어지는 오류이다.^[8]

4. 장단점

쓰레기 수집 기술은 메모리 관리를 자동화하여 프로그래머의 부담을 줄여주지만, 몇 가지 장단점을 가지고 있다.
장점쓰레기 수집이 지원되는 환경에서는 프로그래머가 동적으로 할당한 메모리 영역을 완벽하게 관리할 필요가 없어진다. 이는 다음과 같은 종류의 오류를 줄이거나 완전히 막을 수 있다.^[6]

• 유효하지 않은 포인터 접근 (댕글링 포인터): 이미 해제된 메모리에 접근하는 버그를 방지한다. 해제된 메모리가 다른 용도로 재할당되었을 경우, 잘못된 값을 읽어오는 문제를 막을 수 있다.^[7]
• 이중 해제: 이미 해제된 메모리를 다시 해제하는 버그를 방지한다.
• 메모리 누수: 더 이상 필요하지 않은 메모리가 해제되지 않고 남아있는 버그를 방지한다. 다만, 가비지 컬렉션에서도, 앞으로 사용할 일이 없는 객체에 대한 포인터를 언제까지나 유지하고 있는 코드에서는, 언제까지나 객체가 해제되지 않아 메모리 부족이 발생해 버린다. 이는 논리적인 설계 문제이며, 쓰레기 수집을 사용하는 환경에서도 발생할 수 있다. 객체 (데이터를 저장한 메모리 영역)와 그것을 가리키는 포인터를 관리하므로, 객체는 존재하지만 그것을 가리키는 포인터가 없는 상태를 회피할 수 있다.

• 오버헤드: 어떤 메모리를 해제할지 결정하는 데 컴퓨팅 자원이 소모된다. 객체가 더 이상 필요 없어지는 시점을 프로그래머가 미리 알고 있는 경우에도 쓰레기 수집 알고리즘이 메모리 해제 시점을 추적해야 하므로 오버헤드가 발생하여 프로그램 성능을 저하시킬 수 있다. 2005년에 발표된 논문에 따르면, 쓰레기 수집은 이 오버헤드를 보상하고 명시적 메모리 관리를 사용하는 프로그램만큼 빠르게 실행하기 위해 5배의 메모리가 필요하다는 결론을 내렸다. 하지만 이 비교는 프로파일러에서 실행된 프로그램의 추적을 수집하여 구현된 오라클을 사용하여 할당 해제 호출을 삽입하여 생성된 프로그램과 비교한 것으로, 프로그램은 프로그램의 특정 실행에 대해서만 올바르게 동작한다. 메모리 계층 효과와의 상호 작용은 예측하기 어려운 상황에서 오버헤드를 발생시킬 수 있다. 애플은 이러한 성능 문제를 이유로 iOS에서 쓰레기 수집을 채택하지 않았다.
• 예측 불가능한 실행 중단: 쓰레기 수집이 일어나는 타이밍이나 점유 시간을 미리 예측하기 어렵다. 많은 구현에서는, 뒤섞임으로 인해 잘못하여 도달 가능한 메모리가 불가능하다고 판단되지 않도록, 가비지 컬렉트가 시작되면 다른 처리를 멈추고, 본 처리가 중단된다 (Stop-the-world 가비지 컬렉터). CPU를 장시간 (수백 밀리초에서 수십 초) 점유하는 경우도 있다. 이 때문에 프로그램이 예측 불가능하게 일시적으로 정지할 수 있다. 이러한 특성은 특히 실시간 시스템에는 적합하지 않다. 실시간성을 개선한 GC로, 증분 GC나 동시 GC가 있다. 예측 불가능한 중단은 실시간 환경, 트랜잭션 처리, 또는 대화형 프로그램에서 문제가 될 수 있다. 점진적, 동시적, 실시간 쓰레기 수집기는 이러한 문제를 해결하기 위해 다양한 시도를 하고 있다.
• 자원 해제 시점 통제 불가능: 할당된 메모리가 해제되는 시점을 알 수 없다. 자원 할당과 변수 초기화를 일치시키는 RAII(Resource Acquisition is Initialization) 스타일의 프로그래밍에서는, 자원 해제 시점을 알 수 없다는 것을 의미한다.

4. 1. 장점

• 메모리 조각이 해제되었지만 해당 메모리를 가리키는 포인터가 여전히 존재하고, 그 중 하나가 역참조될 때 발생하는 ''댕글링 포인터''. 이렇게 되면 메모리가 다른 용도로 재할당되었을 수 있으며, 예측할 수 없는 결과가 발생할 수 있다.^[7]
• 프로그램이 이미 해제된 메모리 영역을 다시 해제하려 할 때 발생하는 ''이중 해제 버그''.
• 프로그램이 접근 불가능해진 객체가 차지하는 메모리를 해제하지 못하여 메모리 고갈로 이어질 수 있는 특정 종류의 ''메모리 누수''.^[8]

• 메모리 누수 회피: 가비지 컬렉션은 객체(데이터를 저장한 메모리 영역)와 그것을 가리키는 포인터를 관리하므로, 객체는 존재하지만 그것을 가리키는 포인터가 없는 상태를 회피할 수 있다.
• 객체의 이중 해제 회피: 일단 해제한 객체를 다시 해제하는 것을 방지한다.
• 무효 포인터 회피: 예를 들어, 메모리를 동적으로 할당하는 서브루틴(C 언어의 `malloc` 함수나 파스칼의 `New` 프로시저 등)으로 확보한 메모리 영역을 가리키는 포인터였지만, 메모리를 해제하는 서브루틴 (C 언어의 `free` 함수나 파스칼의 `Dispose` 프로시저 등)에 넘겨 해제한 직후의 포인터나, 서브루틴 내의 자동 변수(비정적인 지역 변수)의 주소를 가리키는 포인터였지만, 반환값 등으로 인해 잘못하여 서브루틴의 호출 측에 반환되어 버린 포인터 등이 해당된다. 이러한 포인터에는 어떤 주소가 대입되어 있지만, 그 주소에는 유효한 객체가 이미 존재하지 않고, 포인터는 무효한 메모리 주소를 가리키고 있다. 이러한 무효한 포인터를 댕글링 포인터라고 하며, 가비지 컬렉션은 이 문제를 회피한다.

4. 2. 단점

5. 쓰레기 수집 전략

쓰레기 수집 전략에는 다양한 알고리즘과 기법이 존재하며, 각각의 특징과 장단점을 가진다.

대부분의 쓰레기 수집 기법은 포인터 추적 방식을 사용한다. 이는 한 개 이상의 변수가 접근 가능한 메모리는 앞으로 사용할 수 있는 메모리로 간주하고, 그 밖의 메모리를 해제하는 방식이다. 접근 가능한 객체는 변수가 직접 가리키는 메모리 또는 간접적으로 가리키는 메모리를 의미하며, 변수에는 콜 스택에서 정의된 지역 변수와 전역 변수가 모두 포함된다. 접근 가능한 메모리는 재귀적으로 정의될 수 있는데, 변수가 가리키는 객체와 접근 가능한 객체가 가리키는 모든 객체는 접근 가능한 것으로 간주된다.

다음은 여러 가지 포인터 추적 기법들이다. 몇몇 언어에서는 아래 나열된 기법들 중 여러 전략을 함께 사용하기도 한다.

• 표식-소거 가비지 컬렉션: 메모리에서 접근 가능한 모든 객체를 "표식"한 후, 메모리 전체를 훑으면서 표식되지 않은 객체들을 "소거"하는 방식이다. 순환 참조를 해결할 수 있지만, 모든 메모리를 훑어야 하므로 비용이 많이 들 수 있다.

• 참조 횟수: 각 객체가 얼마나 많은 참조를 가지고 있는지 추적하는 방식이다. 객체에 대한 참조가 없어지면 즉시 메모리에서 해제된다. 구현이 간단하고 즉각적으로 쓰레기를 회수할 수 있지만, 순환 참조를 해결하지 못한다는 단점이 있다. 파이썬 표준 구현인 CPython에서 이 방식을 사용하며, C++에서는 스마트 포인터라는 특수한 객체를 이용해 이 기법을 구현할 수 있다. 객체가 접근 불가능해지는 즉시 메모리가 해제되므로, 프로그래머가 객체의 해제 시점을 어느 정도 예측할 수 있다는 장점이 있다. 또한, 객체가 사용된 직후에 메모리를 해제하므로, 메모리 해제 시점에 해당 객체는 CPU 캐시에 저장되어 있을 확률이 높아 메모리 해제가 빠르게 이루어진다. 이러한 장점 때문에 참조 횟수 계산 방식은 메모리 관리 뿐 아니라 다른 자원 할당 기법에도 종종 사용된다. 하지만 두 개 이상의 객체가 서로를 가리키고 있을 경우, 참조 횟수가 0이 되지 않아 메모리 누수의 원인이 되는 순환 참조 문제가 발생할 수 있다. CPython은 이 문제를 해결하기 위해 순환 참조를 감지하는 알고리즘을 사용하며, 자료구조에서 약한 참조(참조 횟수를 증가시키지 않는 포인터)를 사용하여 이 문제를 해결할 수도 있다. 멀티스레드 환경에서는 스레드간에 공유하는 객체의 참조 횟수 계산을 위해 원자적 명령을 사용하거나 락을 걸어야 한다는 단점이 있다. 이를 회피하기 위해 스레드 단위 지역 변수로 참조 횟수를 따로 관리하면서, 스레드의 참조 횟수가 0이 될 때만 전역 참조 횟수를 확인하는 방식을 사용할 수 있다. 리눅스 커널에서 이 방식을 사용한다. 또한, 참조 횟수가 0이 될 때 해당 객체가 가리키는 다른 객체들 또한 동시에 0으로 만드는 작업이 일어나는 과정은 경우에 따라 많은 시간이 걸릴 수도 있기 때문에 실시간 시스템에는 적합하지 않을 수 있다.

• 복사 가비지 컬렉션: 메모리를 두 개의 공간으로 나누어, 한 공간이 꽉 차면 다른 공간으로 살아있는 객체들을 복사한다. 이 과정에서 쓰레기는 자연스럽게 제거된다. 빠른 속도를 낼 수 있지만, 메모리 사용량이 두 배로 늘어난다는 단점이 있다.

• 세대별 가비지 컬렉션: 객체의 수명이 짧다는 경험적 관찰에 기반하여, 메모리를 여러 세대로 나누어 더 어린 세대의 객체에 더 자주 가비지 컬렉션을 수행한다. 가비지 컬렉션의 효율성을 높일 수 있으며, 자바의 HotSpot VM이 세대별 가비지 컬렉션을 사용한다. 기존의 GC는 대상 메모리 영역이 가득 찼을 때 한꺼번에 GC를 수행하는 방식인데, 이 방법은 메모리 영역의 크기가 커짐에 따라 GC 시간이 길어지는 단점이 있다. 세대별 GC에서는 신규 영역과 오래된 영역으로 메모리 영역이 나뉘며, 새로 생성된 객체는 신규 영역에 배치되고, 신규 영역이 가득 차면 신규 영역 내부만의 GC가 실행된다. 이 GC는 메모리 전체에 대한 GC에 비해 당연히 부하가 적고 빠르다. 신규 영역에 대한 GC를 일정 횟수 살아남은 객체는 오래된 영역으로 이동하고, 오래된 영역이 가득 찼을 때 처음으로 모든 메모리 영역을 대상으로 하는 FULL GC가 수행된다.

• 정지점 가비지 컬렉션: 객체를 이동시킬 수 없는 환경에서 사용된다. 객체를 이동시키지 않고 메모리 내에서 쓰레기를 회수하는 방식으로, 메모리 단편화 문제를 야기할 수 있다.

5. 1. 포인터 추적 방식

5. 1. 1. 접근 가능한 객체

5. 1. 2. 여러 가지 포인터 추적 기법

• 표식-소거(mark-and-sweep) 가비지 컬렉션: 이 방법은 먼저 메모리에서 접근 가능한 모든 객체를 "표식"한다. 그 후, 메모리 전체를 훑으면서 표식되지 않은 객체들을 "소거"한다. 표식-소거는 순환 참조를 해결할 수 있지만, 모든 메모리를 훑어야 하므로 비용이 많이 들 수 있다.

• 참조 횟수(reference counting): 각 객체가 얼마나 많은 참조를 가지고 있는지 추적한다. 객체에 대한 참조가 없어지면, 즉시 메모리에서 해제된다. 이 방법은 구현이 간단하고 즉각적으로 쓰레기를 회수할 수 있지만, 순환 참조를 해결하지 못한다는 단점이 있다. 파이썬이 참조 횟수 방식을 사용한다.

• 복사 가비지 컬렉션(copying garbage collection): 메모리를 두 개의 공간으로 나누어, 한 공간이 꽉 차면 다른 공간으로 살아있는 객체들을 복사한다. 이 과정에서 쓰레기는 자연스럽게 제거된다. 복사 가비지 컬렉션은 빠른 속도를 낼 수 있지만, 메모리 사용량이 두 배로 늘어난다는 단점이 있다.

• 세대별 가비지 컬렉션(generational garbage collection): 객체의 수명이 짧다는 경험적 관찰에 기반한다. 메모리를 여러 세대로 나누어, 더 어린 세대의 객체에 더 자주 가비지 컬렉션을 수행한다. 이 방법은 가비지 컬렉션의 효율성을 높일 수 있다. 자바의 HotSpot VM이 세대별 가비지 컬렉션을 사용한다.

• 정지점 가비지 컬렉션(immovable garbage collection): 객체를 이동시킬 수 없는 환경에서 사용된다. 객체를 이동시키지 않고 메모리 내에서 쓰레기를 회수하는 방식으로, 메모리 단편화 문제를 야기할 수 있다.

5. 2. 참조 횟수 계산 방식

• 객체가 접근 불가능해지는 즉시 메모리가 해제되므로, 프로그래머가 객체의 해제 시점을 어느 정도 예측할 수 있다.
• 객체가 사용된 직후에 메모리를 해제하므로, 메모리 해제 시점에 해당 객체는 캐시에 저장되어 있을 확률이 높다. 따라서 메모리 해제가 빠르게 이루어진다.

• 두 개 이상의 객체가 서로를 가리키고 있을 경우, 참조 횟수가 0이 되지 않게 된다. 이를 순환 참조라고 하며, 메모리 누수의 원인이 된다. CPython은 이 문제를 해결하기 위해 순환 참조를 감지하는 알고리즘을 사용한다. 또한 자료구조에서 약한 참조(참조 횟수를 증가시키지 않는 포인터)를 사용하여 이 문제를 해결할 수도 있다.
• 다중 스레드 환경에서는, 스레드 간에 공유하는 객체의 참조 횟수 계산을 위해 원자적 명령을 사용하거나 락을 걸어야 한다. 이 문제를 회피하기 위해 스레드 단위 지역 변수로 참조 횟수를 따로 관리하면서, 스레드의 참조 횟수가 0이 될 때만 전역 참조 횟수를 확인하는 방식을 사용할 수 있다. 리눅스 커널에서 이 방식을 사용한다.
• 참조 횟수가 0이 될 때, 해당 객체가 가리키는 다른 객체들 또한 동시에 0으로 만드는 작업이 일어난다. 이 과정은 경우에 따라 많은 시간이 걸릴 수도 있기 때문에 실시간 시스템에는 적합하지 않을 수 있다.

• 순환 참조: 두 개 이상의 객체가 서로를 참조하는 경우, 상호 참조로 인해 순환 참조가 생성되어 참조 계수가 0이 되지 않아 아무것도 수집되지 않을 수 있다. 참조 계수를 사용하는 일부 가비지 컬렉션 시스템(예: CPython)은 이 문제를 해결하기 위해 특정 순환 참조 감지 알고리즘을 사용한다. 또 다른 전략은 순환 참조를 생성하는 "백포인터"에 약한 참조를 사용하는 것이다. 참조 계수에서 약한 참조는 추적 가비지 수집기에서의 약한 참조와 유사하다. 이는 해당 객체의 존재가 참조된 객체의 참조 계수를 증가시키지 않는 특수한 참조 객체이다. 또한, 약한 참조는 참조된 객체가 가비지가 될 때, 해당 객체에 대한 약한 참조가 댕글링된 상태로 유지되는 것이 아니라, null 참조와 같은 예측 가능한 값으로 "만료"되므로 안전하다.
• 공간 오버헤드(참조 계수): 참조 계수는 각 객체의 참조 계수를 저장하기 위해 공간을 할당해야 한다. 계수는 객체의 메모리 옆에 저장하거나 다른 곳의 사이드 테이블에 저장할 수 있지만, 어느 경우든 참조 계수가 있는 모든 객체는 참조 계수를 위한 추가 저장 공간이 필요하다. 부호 없는 포인터 크기의 메모리 공간이 일반적으로 이 작업에 사용되므로 각 객체에 대해 32비트 또는 64비트의 참조 계수 저장 공간을 할당해야 한다. 일부 시스템에서는 태그된 포인터를 사용하여 객체 메모리의 사용하지 않는 영역에 참조 계수를 저장하여 이 오버헤드를 완화할 수 있다. 종종 아키텍처는 프로그램이 네이티브 포인터 크기에 저장할 수 있는 전체 메모리 주소 범위에 실제로 액세스하도록 허용하지 않는다. 주소의 특정 수의 상위 비트는 무시되거나 0이어야 한다. 객체가 특정 위치에 포인터를 안정적으로 가지고 있는 경우 참조 계수를 포인터의 사용하지 않는 비트에 저장할 수 있다. 예를 들어, Objective-C의 각 객체는 메모리의 시작 부분에 해당 클래스에 대한 포인터를 가지고 있다. iOS 7을 사용하는 ARM64 아키텍처에서 이 클래스 포인터의 19개의 사용하지 않는 비트가 객체의 참조 계수를 저장하는 데 사용된다.
• 속도 오버헤드(증가/감소): 단순한 구현에서는 참조 할당과 범위 밖으로 벗어나는 각 참조가 하나 이상의 참조 카운터를 수정해야 하는 경우가 많다. 그러나 외부 범위 변수에서 내부 범위 변수로 참조가 복사되는 일반적인 경우, 내부 변수의 수명이 외부 변수의 수명에 의해 제한되므로 참조 증가를 제거할 수 있다. 외부 변수가 참조를 "소유"한다. C++ 프로그래밍 언어에서는 이 기술이 `const` 참조를 사용하여 쉽게 구현되고 시연된다. C++의 참조 계수는 일반적으로 참조를 관리하는 "스마트 포인터"를 사용하여 구현된다. 스마트 포인터는 함수에 참조로 전달될 수 있으며, 이는 새로운 스마트 포인터를 복사 생성할 필요를 없애준다(이는 함수에 들어가면 참조 계수를 증가시키고 함수에서 나오면 감소시킨다). 대신 함수는 저렴하게 생성되는 스마트 포인터에 대한 참조를 받는다. Deutsch-Bobrow의 참조 계수 방법은 대부분의 참조 계수 업데이트가 실제로 지역 변수에 저장된 참조에 의해 생성된다는 사실을 이용한다. 이 방법은 이러한 참조를 무시하고 힙의 참조만 계산하지만, 참조 계수가 0인 객체를 삭제하기 전에 시스템은 스택과 레지스터를 스캔하여 해당 객체에 대한 다른 참조가 아직 존재하지 않는지 확인해야 한다. 페트랭크가 도입한 업데이트 통합을 통해 카운터 업데이트에 대한 오버헤드를 더욱 크게 줄일 수 있다. 주어진 실행 간격 동안 여러 번 업데이트되는 포인터를 생각해 보십시오. 먼저 객체 `O1`을 가리킨 다음 객체 `O2`를 가리키며, 간격이 끝날 때까지 객체 `On`을 가리킨다. 참조 계수 알고리즘은 일반적으로 `rc(O1)--`, `rc(O2)++`, `rc(O2)--`, `rc(O3)++`, `rc(O3)--`, ..., `rc(On)++`를 실행한다. 그러나 이러한 업데이트의 대부분은 중복된다. 간격이 끝날 때 참조 계수를 적절하게 평가하려면 `rc(O1)--` 및 `rc(On)++`를 수행하는 것으로 충분하다. 페트랭크는 일반적인 Java 벤치마크에서 카운터 업데이트의 99% 이상이 제거되는 것을 측정했다.
• 원자성 필요: 다중 스레드 환경에서 사용될 때, 이러한 수정(증가 및 감소)은 여러 스레드 간에 공유되거나 잠재적으로 공유되는 객체의 경우, 원자적 연산 (예: 비교 후 교환)이 필요할 수 있다. 원자적 연산은 멀티프로세서에서 비용이 많이 들고, 소프트웨어 알고리즘으로 에뮬레이션해야 하는 경우 더욱 비싸다. 스레드별 또는 CPU별 참조 계수를 추가하고 지역 참조 계수가 0이 되거나 더 이상 0이 아닐 때에만 전역 참조 계수에 액세스하거나 (또는, 대안으로 참조 계수의 이진 트리를 사용하거나, 아예 전역 참조 계수를 갖지 않는 대신 결정적 파괴를 포기) 이 문제를 피할 수 있지만, 이는 상당한 메모리 오버헤드를 추가하므로 특수한 경우에만 유용한 경향이 있다(예: Linux 커널 모듈의 참조 계수에 사용됨). 페트랭크의 업데이트 통합을 사용하면 쓰기 장벽에서 모든 원자적 연산을 제거할 수 있다. 카운터는 프로그램 실행 중에 프로그램 스레드에 의해 절대 업데이트되지 않는다. 단일 추가 스레드로 실행되는 수집기에 의해서만 수정되며 동기화가 없다. 이 방법은 병렬 프로그램에 대한 전체 정지 메커니즘으로 사용할 수 있으며, 동시 참조 계수 수집기와 함께 사용할 수도 있다.
• 실시간 아님: 참조 계수의 단순한 구현은 일반적으로 실시간 동작을 제공하지 않는다. 왜냐하면 모든 포인터 할당이 스레드가 다른 작업을 수행할 수 없는 동안 총 할당된 메모리 크기에 의해서만 제한되는 여러 객체를 재귀적으로 해제할 수 있기 때문이다. 추가 오버헤드를 감수하고, 참조되지 않은 객체의 해제를 다른 스레드에 위임하여 이 문제를 피할 수 있다.

5. 2. 1. 장점

• 객체가 접근 불가능해지는 즉시 메모리가 해제되므로, 프로그래머가 객체의 해제 시점을 예측할 수 있다.
• 메모리 해제가 빠르게 이루어진다.

5. 2. 2. 단점

5. 3. 이스케이프 분석

6. 쓰레기 수집 방식에 따른 분류

쓰레기 수집 방식은 크게 프로그램 중단 여부에 따라 스톱-더-월드(Stop-the-World) 방식과 컨커런트(Concurrent) 방식으로 나뉜다.

스톱-더-월드 방식은 가비지 컬렉션을 수행하기 위해 프로그램 실행을 완전히 중단하는 방식이다. 이 방식은 구현이 간단하지만, 프로그램의 응답 시간을 지연시키는 단점이 있다.

컨커런트 방식은 프로그램 실행과 동시에 가비지 컬렉션을 수행하는 방식이다. 이 방식은 프로그램 응답 시간 지연을 최소화할 수 있지만, 구현이 복잡하다.

6. 1. 스톱-더-월드 방식

6. 2. 컨커런트 방식

7. 쓰레기 수집이 필요한 환경

쓰레기 수집은 자원 사용에 대한 엄격한 통제가 필요하므로 임베디드 시스템이나 실시간 시스템에서는 사용이 제한적이다. 하지만 여러 제한된 환경에 적용 가능한 쓰레기 수집기가 개발되어 왔다. .NET 마이크로 프레임워크와 .NET 나노프레임워크, 자바 플랫폼, 마이크로 에디션 등의 임베디드 소프트웨어 플랫폼은 대규모 플랫폼과 마찬가지로 쓰레기 수집 기능을 포함하고 있다.

7. 1. 제한된 환경

8. 프로그래밍 언어별 지원 현황

다음은 "쓰레기 수집 (컴퓨터 과학)" 위키 페이지의 "프로그래밍 언어별 지원 현황" 섹션 내용이다.

많은 현대 프로그래밍 언어들이 쓰레기 수집 기법을 활용한다. C와 C++는 기본적으로 쓰레기 수집을 지원하지 않지만, Boehm garbage collector와 같은 라이브러리를 통해 해당 기능을 추가할 수 있다. 다만, 라이브러리 기반 방식은 객체 생성 및 소멸 메커니즘 변경이 필요하다는 단점이 있다.

ML, 하스켈, 얼랭, APL 등 대부분의 함수형 프로그래밍 언어는 가비지 컬렉션을 내장하고 있다. 특히 Lisp는 최초의 함수형 언어이자 쓰레기 수집을 도입한 최초의 언어로서 중요한 의미를 가진다.

자바, 스몰토크, 자바스크립트, ECMAScript 등 객체 지향 프로그래밍 언어들은 대부분 가비지 컬렉션을 기본적으로 제공한다. 자바 JDK에서는 G1, Parallel, CMS, Serial, C4, Shenandoah, ZGC 등의 다양한 가비지 컬렉터를 사용할 수 있다. 하지만 델파이와 C++는 쓰레기 수집을 기본적으로 지원하지 않고 소멸자를 통해 메모리를 관리한다.

루비, Julia와 같은 동적 타입 언어들도 가비지 컬렉션을 사용하며, 파이썬은 주로 참조 횟수 계산 방식을 사용하지만, 세대별 GC를 병행한다.^[19][20] Perl 5나 5.3 이전 버전의 PHP는 참조 카운팅 방식만 사용했다. C#이나 Visual Basic .NET과 같은 .NET 언어는 .NET Framework/.NET Compact Framework/Mono/.NET Core 등 실행 환경에서 가비지 컬렉션을 이용할 수 있다.

Rust는 가비지 컬렉션 대신 소유권 개념을 통해 메모리를 관리하며,^[14] C++처럼 소멸자를 정의하거나 참조 카운트 기반 스마트 포인터를 사용할 수 있다.

초창기 베이직 인터프리터에서도 가비지 컬렉션 기능이 제공되어, 문자열 연결 연산 후 불필요해진 영역을 재활용했다. 당시에는 가비지 컬렉션 실행 중 프로그램이 멈추는 현상이 발생하기도 했다.

Objective-C는 원래 참조 카운트 기반 객체 생명주기 관리 방식을 사용했으며 가비지 컬렉션 기능은 없었다. 하지만 애플(Apple Inc.)은 OS X 10.5부터 Objective-C 2.0에 자체 개발한 보수적인 세대별 GC 기반 런타임 수집기를 도입했다. 하지만 iOS에서는 애플리케이션 응답성 및 성능 문제로 인해 가비지 컬렉션이 도입되지 않았고, ARC (Automatic Reference Counting)를 사용한다. macOS에서도 `NSGarbageCollector`는 OS X 10.8부터 폐지 예정되었고, SDK 10.10을 마지막으로 폐지되었으며,^[16] OS X 10.11을 마지막으로 해당 GC는 더 이상 탑재되지 않았으며,^[17] macOS 10.12에서 완전히 폐지되었다. 2015년 5월 이후, Mac App Store에 신규 등록/갱신되는 앱은 GC를 사용할 수 없게 되었다.^[18] 대안으로 ARC가 권장되고 있으며, Swift 또한 ARC를 채택하고 있다. 한편, GNUstep은 Boehm GC를 사용한다.

C++/CLI에서는 `gcnew`로 생성된 CLI 객체가 .NET Framework의 가비지 컬렉션에 의해 관리된다. C++/CX에서는 `ref new`로 생성된 Windows 런타임 객체가 COM 기반 참조 카운트에 의해 관리된다.

8. 1. 함수형 프로그래밍 언어

8. 2. 객체 지향 언어

• G1
• Parallel
• 동시 마크 스윕 컬렉터 (CMS)
• Serial
• C4 (Continuously Concurrent Compacting Collector)
• Shenandoah
• ZGC

8. 3. 기타 언어

9. 관련 라이브러리 및 도구

C/C++에서는 다음과 같은 가비지 컬렉션 라이브러리와 스마트 포인터 도구를 사용할 수 있다.

• Boehm GC: C/C++용 마크 앤 스위프 방식 가비지 컬렉터이다.

• Boost C++ 라이브러리의 `boost::shared_ptr` 및 `boost::shared_array`. 참조 계수의 증가 및 감소 처리를 커스터마이징할 수 있는 `boost::intrusive_ptr`도 있다.
• C++11 이후의 `std::shared_ptr`
• Active Template Library의 `ATL::CComPtr` - COM 객체의 스마트 포인터이다.
• Windows 런타임의 `Microsoft::WRL::ComPtr` - Windows 런타임 객체의 스마트 포인터이며, COM 객체에도 사용 가능하다.

참조

_[1] 웹사이트 What is garbage collection (GC) in programming? https://www.techtarg[...] 2024-06-21
_[2] 웹사이트 What is garbage collection (GC) in programming? https://www.techtarg[...] 2022-10-17
_[3] 웹사이트 What is garbage collection? Automated memory management for your programs https://www.infoworl[...] 2023-02-03
_[4] 웹사이트 A Guide to Garbage Collection in Programming https://www.freecode[...] 2020-01-16
_[5] 웹사이트 Garbage Collection - D Programming Language https://dlang.org/sp[...] 2022-10-17
_[6] 웹사이트 Garbage Collection https://rebelsky.cs.[...] 2024-01-13
_[7] 웹사이트 What is garbage collection? Automated memory management for your programs https://www.infoworl[...] 2023-02-03
_[8] 웹사이트 Fundamentals of garbage collection {{!}} Microsoft Learn https://learn.micros[...] 2023-03-29
_[9] 문서 Recursive functions of symbolic expressions and their computation by machine, Part I http://portal.acm.or[...]
_[10] 문서 RECURSIVE FUNCTIONS OF SYMBOLIC EXPRESSIONS AND THEIR COMPUTATION BY MACHINE (Part I) (12-May-1998) http://www-formal.st[...]
_[11] 간행물 分散記憶並列計算機における局所ごみ集めのスケジュール方式について http://id.nii.ac.jp/[...] 情報処理学会 2000-05
_[12] 간행물 Java-ASにおけるガベージコレクション対策に関する一考察 電子情報通信学会 2010-03
_[13] 웹사이트 古典的Javaガベージコレクションを理解する https://www.infoq.co[...] 2020-09-15
_[14] 뉴스 メモリー管理を安全に、次代のシステムプログラミング言語「Rust」の魅力とは | 日経クロステック（xTECH） https://xtech.nikkei[...]
_[15] 웹사이트 メモリ管理を理解する（後編） (2/2)：Cocoaの素、Objective-Cを知ろう（8） - ＠IT https://www.atmarkit[...] 2019-02-14
_[16] 웹사이트 NSGarbageCollector - Foundation {{!}} Apple Developer Documentation https://developer.ap[...] 2019-02-14
_[17] 웹사이트 Xcode Release Notes {{!}} Xcode 8.3 https://developer.ap[...] 2019-02-14
_[18] 웹사이트 Apple Warns Developers Garbage Collection is Dead, Move to ARC – The Mac Observer https://www.macobser[...] 2019-02-14
_[19] 웹사이트 29.11. gc — ガベージコレクタインターフェース — Python 3.6.5 ドキュメント https://docs.python.[...] 2019-02-10
_[20] 웹사이트 Garbage Collection for Python http://arctrix.com/n[...] 2019-02-10
_[21] 웹인용 Recursive functions of symbolic expressions and their computation by machine, Part I http://www-formal.st[...] 2012-11-13