2nd/01_Archive/2026-04-20/V8 가비지 컬렉션(Garbage Collection).md

---
id: P-REINFORCE-AUTO-488812
category: "10_Wiki/💡 Topics/Programming & Language"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - V8 가비지 컬렉션(Garbage Collection)"
---

# [[V8 가비지 컬렉션(Garbage Collection)|V8 가비지 컬렉션(Garbage Collection)]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> V8 가비지 컬렉션은 애플리케이션의 메모리를 자동으로 관리하기 위해 더 이상 사용되지 않는 죽은 메모리 영역을 식별하고 운영체제로 반환하거나 재사용하는 프로세스입니다 [1]. 가비지 컬렉터는 루트(Root) 객체에서 시작하는 포인터 체인을 통해 도달할 수 없는 객체를 죽은 객체(가비지)로 간주하여 처리합니다 [1, 2]. V8은 대다수의 객체가 일찍 죽는다는 특성을 활용하여 힙 메모리를 세대별로 분할하고, 각 공간에 최적화된 마이너 GC(Minor GC)와 메이저 GC(Major GC)를 수행합니다 [3, 4].

## 📖 구조화된 지식 (Synthesized Content)
**힙 메모리 구조 (Heap Organization)**
V8은 힙을 객체의 생존 기간 및 용도에 따라 여러 공간으로 분할합니다 [5]. 
- **New-space**: 대부분의 새로운 객체가 할당되는 작고 빠른 영역입니다 [5].
- **Old-space**: New-space에서 일정 시간 살아남은 객체들이 이동하는 영역으로, 다른 객체를 가리키는 포인터가 포함된 'Old-pointer-space'와 원시 데이터만 포함된 'Old-data-space'로 세분화됩니다 [5]. 
- **그 외 공간**: 이 외에도 대용량 객체를 위한 'Large-object-space', 실행 가능한 코드를 저장하는 'Code-space', 그리고 크기가 일정한 내부 객체 관리를 위한 'Cell/Map-space' 등이 존재합니다 [5]. 
각 공간은 연속된 메모리 청크인 여러 개의 페이지(Page)로 구성되며, 각 페이지는 일반적으로 1MB 또는 512KB의 크기로 관리됩니다 [6, 7].

**포인터 식별 (Tagged Pointers)**
가비지 컬렉터가 힙 내에서 살아있는 객체를 탐색하려면 포인터와 일반 데이터를 구분해야 합니다 [8]. V8은 컴파일러의 제한적인 지원만으로도 효율적으로 식별이 가능한 '태그된 포인터(Tagged pointers)' 방식을 사용합니다 [9]. 각 워드의 마지막 비트를 예약하여 데이터와 포인터를 구분하므로 가비지 컬렉터가 객체 스캔 시 정수를 무시하고 포인터만 빠르게 따라갈 수 있습니다 [9, 10].

**세대별 가비지 컬렉션 (Generational Collection)**
- **마이너 GC (Scavenge)**: New-space를 관리하는 가비지 컬렉터로, 할당 포인터가 New-space의 끝에 도달하면 시작됩니다 [3, 11]. 체니(Cheney)의 알고리즘을 기반으로 New-space를 크기가 같은 두 개의 반공간(To-space와 From-space)으로 나누어 작동합니다 [11, 12]. 가비지 컬렉션이 트리거되면 살아있는 객체만 To-space로 대피시키며(복사 및 압축), 두 번의 사이클에서 살아남은 객체는 Old-space로 승격(Promote)시킵니다 [11, 13].
- **메이저 GC (Mark-Sweep-Compact)**: 크기가 큰 Old-space의 가비지를 수집하기 위해 마킹(Marking), 스위핑(Sweeping), 압축(Compacting) 단계를 거칩니다 [14]. 마킹 단계에서는 힙을 방향성 그래프로 간주하여 깊이 우선 탐색(DFS)을 수행하고 객체 상태를 흰색, 회색, 검은색 비트로 표시합니다 [15, 16]. 이후 마킹되지 않은 죽은 객체의 영역을 찾아 여유 공간으로 반환하는 스위핑 작업이나, 살아있는 객체를 모아 메모리 단편화를 줄이는 압축 작업을 수행합니다 [17, 18].

**Orinoco와 최신 GC 최적화**
과거의 가비지 컬렉터는 메인 스레드를 멈추는 'Stop-the-world' 방식으로 인해 지연 시간이 발생했습니다 [19]. V8은 Orinoco 프로젝트를 통해 이 한계를 극복하고 다양한 최적화 기법을 도입했습니다 [20, 21].
- **Parallel (병렬)**: 메인 스레드와 헬퍼 스레드가 동시에 가비지 컬렉션 작업을 분담하여 총 일시 중지 시간을 줄입니다 [22].
- **Incremental (점진적)**: 메인 스레드가 JS 실행 중간중간에 작은 조각 단위로 마킹 작업을 수행하여 긴 멈춤을 방지합니다 [19, 23].
- **Concurrent (동시)**: 메인 스레드가 JS를 계속 실행하는 동안 백그라운드의 헬퍼 스레드가 완전히 독립적으로 마킹 및 스위핑을 수행합니다 [24, 25].
메인 스레드 실행 중 객체 그래프가 변경되는 문제는 쓰기 장벽(Write barriers)을 통해 지속적으로 변경사항을 추적하여 해결합니다 [26, 27].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[세대별 가설(Generational Hypothesis)|세대별 가설(Generational Hypothesis)]], [[마크-스위프-컴팩트(Mark-Sweep-Compact)|마크-스위프-컴팩트(Mark-Sweep-Compact)]], 마이너 GC(Scavenge), [[Orinoco 가비지 컬렉터|Orinoco 가비지 컬렉터]]
- **Projects/Contexts:** [[Node.js|Node.js]], Chrome V8 엔진, [[Orinoco 프로젝트|Orinoco 프로젝트]]
- **Contradictions/Notes:** 소스에 따르면 과거의 Scavenge 알고리즘은 동기식(Synchronous)인 체니(Cheney) 알고리즘을 구현하였으나, Chrome과 Node.js가 구동되는 현대의 멀티코어 환경에 발맞추어 현재의 V8은 다중 스레드를 활용해 동적으로 작업을 분배하는 병렬(Parallel) Scavenger로 진화했습니다 [28, 29].

---
*Last updated: 2026-04-19*
- Raw Source: 00_Raw/2026-04-20/V8 가비지 컬렉션(Garbage Collection).md
---