가비지 컬렉션의 전체 비용

가비지 컬렉션의 비용은 여러 시스템, 특히 Lisp와 Smalltalk 시스템에서 연구되어 왔습니다. 그러나 이러한 연구들 대부분은 심각한 한계를 가지고 있습니다. 흔한 한계 중 하나는 느린 언어 구현의 사용입니다. 예를 들어 인터프리터, 해석 가상 머신, 또는 부실한 컴파일러 등이 그것입니다. 프로그램이 비현실적으로 느리게 실행되면, 가비지 컬렉션의 CPU 비용은 매우 낮게 나타납니다. 비용 연구의 또 다른 흔한 한계는 “장난감” 프로그램이나 합성 벤치마크의 사용입니다. 이러한 프로그램들은 종종 대규모 실제 애플리케이션과 매우 다르게 동작합니다. 종종 이들은 오래 살아남는 데이터가 거의 없어서, 추적 수집이 비현실적으로 효율적으로 보이게 만듭니다. 이는 또한 세대별 수집기의 쓰기 장벽 비용 측정에도 영향을 미칠 수 있는데, 오래 살아남는 데이터가 적은 프로그램은 세대 간 포인터를 많이 생성하지 않기 때문입니다.

또 다른 어려움은 대부분의 연구가 가비지 컬렉션 구현의 이후 개선사항들로 인해 다소 구식이 되었다는 것입니다. 따라서 가장 가치 있는 연구는 다양한 전략들이 어떻게 작동할지 추론하는 데 사용할 수 있는, 다양한 이벤트에 대한 상세한 통계를 제공하는 것들입니다.

아마도 현재까지 최고의 연구는 Zorn의 대규모 상용 Common Lisp 시스템에서 8개의 대형 프로그램을 사용한 GC 비용 조사일 것입니다. Zorn은 세대별 가비지 컬렉션의 시간 비용이 5%에서 20% 사이임을 발견했습니다. (우리는 빠른 카드 마킹 쓰기 장벽을 사용하면 이 수치를 크게 개선할 수 있을 것으로 생각합니다.) Shaw의 논문은 유사한 성능 수치를 제공하며, Steenkiste의 논문에는 유사한 관련 통계가 포함되어 있습니다.

Zorn은 또한 보수적 포인터 찾기를 사용하는 단순한 비세대별 수집기를 연구했습니다. 이를 통해 그는 고성능 C 언어 구현을 사용하여 가비지 컬렉션을 연구하고, 가비지 컬렉션 비용을 명시적 할당 해제의 다양한 구현과 비교할 수 있었습니다. 불행히도, 사용된 가비지 수집기는 컴파일러 협력 부족 등의 이유로 최신 기술이 아니었습니다. Zorn은 잘 구현된 malloc()과 free()를 사용하는 것과 비교했을 때, 단순 보수적 GC를 사용하는 프로그램이 CPU 시간은 0%에서 36% 더 사용하고, 메모리는 40%에서 280% 더 사용한다는 것을 발견했습니다. 그러나 Zorn의 테스트 프로그램들은 비정상적으로 힙 할당 집약적이었으며, 더 일반적인 작업 부하에서는 비용이 더 낮을 것으로 추정됩니다. 우리는 또한 최신 세대별 수집기와 컴파일러 협력을 통해 이 수치들을 상당히 개선할 수 있다고 믿습니다.

Tarditi와 Diwan은 Standard ML of NJ에서 가비지 컬렉션 비용을 연구했고, 가비지 컬렉션의 총 시간 비용이 22%에서 40% 사이임을 발견했습니다. 이는 매우 흥미롭고 유익한 연구이지만, 우리는 이 수치가 불필요하게 높다고 생각합니다. 이는 스택이 아닌 힙에 엄청난 양의 활성화 정보와 바인딩 환경을 할당하여 가비지 수집기에 극심한 부하를 주었기 때문입니다. 우리는 또한 그들의 쓰기 장벽이 개선될 수 있다고 믿습니다.

잘 구현된 비증분 세대별 시스템(고성능 언어 구현용)에서 가비지 컬렉션의 일반적인 비용에 대한 우리 자신의 추정은, 잘 구현된 명시적 힙 관리 시스템에 비해 실행 시간의 약 10% 정도의 비용이 들고, 데이터 메모리 크기는 약 2배의 공간 비용이 들 것으로 봅니다. (당연히 증가된 CPU 비용은 감소된 공간 비용과 교환될 수 있습니다.) 그러나 이것은 기존 시스템의 결함과 현재까지의 연구 한계를 보완한 교육적 추측으로 받아들여야 합니다.

분명히, 특히 강타입 언어의 우수한 구현을 위한 고성능 시스템에서의 가비지 컬렉션에 대한 더 많은 연구가 필요합니다.

측면	원문 연구 (1990년대)	최신 연구 (2020년대)
세대별 GC 시간 비용	5-20%	3-10%
보수적 GC 오버헤드	0-36% CPU, 40-280% 메모리	현대적 구현에서는 크게 개선
일시 정지 시간	수십-수백 밀리초	서브밀리초~10ms
메모리 오버헤드	약 2배	1.2-1.5배 (압축 기술 사용)

시간 비용:

마이너 수집: 전체 실행 시간의 1-3%
메이저 수집: 전체 실행 시간의 2-7%
총 GC 오버헤드: 약 5-10% (명시적 메모리 관리 대비)

공간 비용:

마이너 힙 기본 크기: 2MB
메이저 힙 오버헤드: 라이브 데이터의 1.5-2배
헤더 오버헤드: 객체당 1 워드 (8바이트, 64비트 시스템)

종합 비교

언어/시스템	GC 시간 비용	메모리 오버헤드	특징
원문 추정치	~10%	~2배	일반적 세대별 GC
최신 Java/Go	3-10%	1.2-1.5배	동시 병렬 GC
OCaml	5-10%	1.5-2배	하이브리드 증분 GC
원문 SML/NJ	22-40%	높음	극심한 힙 사용

OCaml의 장단점

장점:

✅ 예측 가능한 낮은 일시 정지 시간
✅ C/C++와의 안전한 인터페이스
✅ 함수형 프로그래밍에 최적화된 할당 패턴

단점:

❌ 단일 코어 GC (OCaml 4.x까지)
❌ 멀티코어 환경에서 확장성 제한
❌ OCaml 5.0에서 멀티코어 GC 도입으로 개선 중

결론: OCaml의 GC 비용은 원문에서 제시한 “잘 구현된 시스템”의 추정치(~10%)와 최신 고성능 GC 시스템의 범위 내에 있으며, 특히 함수형 프로그래밍 워크로드에서 효율적입니다.

가비지 컬렉션의 전체 비용

최신 연구와의 비교 (2025년 기준)

최신 연구 동향 (2020년대)

원문과의 비교

OCaml 가비지 컬렉션 비용 분석

OCaml GC 특징

OCaml GC 비용 추정

종합 비교

OCaml의 장단점