2nd/10_Wiki/Topics/Architecture/Old_Space(Old_Generation).md

---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Old Space(Old Generation)|Old Space(Old Generation]]
last_updated: 2026-05-02
---

# [[Old Space(Old Generation)|Old Space(Old Generation]]

## 📌 Brief Summary
> Old Space(또는 Old Generation)는 V8 엔진의 힙(Heap) 메모리 영역 중 하나로, [[New Space(Young Generation)|New Space(Young Generation]]에서 두 번의 마이너 가비지 컬렉션(Scavenge) 주기 동안 살아남은 수명이 긴 객체들이 이동(승격)하여 저장되는 공간이다 [1-3]. 이 공간은 주로 사용자 세션, 캐시 데이터 등 영구적인 상태를 유지하는 데이터 저장에 사용되며, New Space에 비해 크기가 훨씬 크고 가비지 컬렉션([[Major GC|Major GC]])이 덜 빈번하게 발생하지만 더 많은 컴퓨팅 리소스를 소모한다 [4, 5].

---

> V8 엔진의 힙(Heap) 메모리 구조에서 '이전 세대(Old Generation 또는 [[Old Space|Old Space]])'는 신세대(New Space)에서 발생하는 여러 번의 마이너 가비지 컬렉션(스캐빈지)을 거치고 살아남은, 수명이 긴 객체들이 승격(Promote)되어 저장되는 메모리 공간입니다 [1-4]. 이 공간은 데이터의 특성에 따라 포인터가 있는 공간(Old-pointer-space)과 순수 데이터만 있는 공간(Old-data-space)으로 나뉘며, 메이저 가비지 컬렉터([[Major GC|Major GC]])에 의해 관리됩니다 [4-6].

## 📖 Core Content
*   **객체의 승격(Promotion) 및 수명:** 
    V8의 메모리 관리는 대부분의 객체가 짧은 수명을 가진다는 '세대적 가설([[Generational Hypothesis|Generational Hypothesis]])'에 기반한다 [6]. 초기에 New Space에 할당된 객체가 두 번의 스캐빈지(Scavenge) 주기를 거친 후에도 살아남으면, 장기 보관을 위해 설계된 Old Space로 승격(Promoted)된다 [1, 3, 4]. 전체 객체 중 약 20%만이 Old Generation 영역으로 살아남게 된다 [7].
*   **Old Space의 세부 구조:**
    가비지 컬렉션의 효율을 높이기 위해 Old Space는 내부적으로 크게 두 가지 공간으로 세분화된다 [3, 8].
    *   **Old-pointer-space:** 다른 객체를 가리키는 포인터를 포함할 가능성이 있는 대부분의 객체가 저장된다 [3, 9].
    *   **Old-data-space:** 문자열(Strings), 박싱된 숫자, 포인터가 없는 원시 데이터 배열 등 외부 객체에 대한 포인터를 포함하지 않는 객체들이 저장된다 [3, 9]. 가비지 컬렉터는 이 영역에서 포인터 추적(tracing) 단계를 건너뛸 수 있으므로 마킹 단계의 소요 시간을 효과적으로 단축한다 [4].
*   **가비지 컬렉션(Major GC) 관리:** 
    Old Space는 수백 메가바이트 이상의 데이터를 포함할 수 있으므로, Scavenge 알고리즘 대신 **[[Mark-Sweep|Mark-Sweep]]** 및 **Mark-Compact** 알고리즘을 사용하는 Major GC에 의해 관리된다 [10-12]. Major GC는 힙을 순회하며 살아있는 객체를 표시(Mark)하고, 참조되지 않는 객체의 메모리 주소를 빈 공간(Free list)으로 기록(Sweep)하며, 필요한 경우 메모리 파편화(Fragmentation)를 줄이기 위해 객체들을 한곳으로 모으는 압축(Compact) 작업을 수행한다 [13-16]. 
*   **메모리 제어 및 튜닝:** 
    Old Space의 크기는 `--initial_old_space_size`와 `--max-old-space-size`라는 V8 커맨드라인 플래그를 통해 제어할 수 있다 [3, 17]. 대량의 영구 데이터나 사용자 세션 정보를 처리하는 애플리케이션의 경우, 장기 생존 객체가 Old Space에 가득 차면 빈번하고 비용이 큰 가비지 컬렉션이 발생해 응답 속도 저하 또는 OOM(Out of [[memory|memory]]) 충돌이 일어날 수 있으므로 해당 플래그를 통해 Old Space의 제한 크기를 늘리는 튜닝이 권장된다 [5, 17].

---

* **이전 세대 메모리의 구조 및 세분화**
  이전 세대는 수백 메가바이트의 데이터를 포함할 수 있는 매우 큰 공간으로, 내부적으로 두 개의 주요 공간으로 나뉩니다 [7].
  * **Old-pointer-space:** 다른 객체를 가리키는 포인터를 포함할 수 있는 대부분의 살아남은 객체들이 보관되는 곳입니다 [4-6].
  * **Old-data-space:** 포인터 없이 순수하게 원시 데이터만 포함하는 객체(예: 문자열, 박스화된 숫자, 언박싱된 더블 배열 등)가 위치합니다 [4-6]. 이 공간에서는 객체가 다른 객체로의 포인터를 가지지 않는다는 것을 GC가 알고 있기 때문에, 마킹(Marking) 시 포인터 추적 단계를 건너뛰어 성능을 최적화할 수 있습니다 [2].

* **메이저 가비지 컬렉션(Major GC)**
  이전 세대는 공간이 크기 때문에 신세대에서 사용하는 스캐빈지([[Scavenge|Scavenge]]) 알고리즘(To-Space와 From-Space를 이용한 복사 방식)을 적용하는 것이 물리적 메모리 오버헤드 측면에서 비실용적입니다 [7, 8]. 따라서 마크-스윕([[Mark-Sweep|Mark-Sweep]])과 마크-컴팩트(Mark-Compact)라는 두 가지 주요 알고리즘을 사용합니다 [7, 9, 10].
  * **Mark (마킹):** 깊이 우선 탐색(DFS) 알고리즘을 사용하여 루트(Root)에서 접근 가능한 활성 객체(Live objects)를 찾아 검은색(Black)으로 표시합니다 [11-13].
  * **Sweep (스윕):** 마킹되지 않은 연속된 데드 객체들을 스캔하여 이를 여유 공간(Free lists)으로 변환함으로써 메모리를 재사용할 수 있게 합니다 [14, 15].
  * **Compact (컴팩트):** 메모리 단편화(Fragmentation)가 심한 페이지의 활성 객체를 다른 페이지의 빈 공간으로 복사(이주)시키고 원래 공간을 해제하여 메모리 효율을 높입니다 [9, 16, 17]. 이동 비용이 높기 때문에 모든 경우에 수행되지는 않고 필요에 따라 선별적으로 공격적인 압축을 수행합니다 [9, 18].

* **최적화: 점진적 마킹 및 지연 스윕([[Incremental Marking|Incremental Marking]] & Lazy Sweeping)**
  대규모 이전 세대 메모리를 한 번에 수집하려고 하면 수백 밀리초에 달하는 긴 애플리케이션 지연([[Stop-the-world|Stop-the-world]] pause)이 발생할 수 있습니다 [17, 19]. 이를 방지하기 위해 가비지 컬렉션을 작은 단계로 나누어 메인 스레드의 [[JavaScript|JavaScript]] 실행과 교차 수행하는 '점진적 마킹(Incremental marking)'과, 모든 페이지를 한 번에 스윕하지 않고 메모리가 필요한 시점까지 스윕을 미루는 '지연 스윕(Lazy sweeping)' 기법을 사용합니다 [17, 19-22].

* **쓰기 장벽([[Write Barrier|Write Barrier]]s)과 포인터 추적**
  이전 세대의 객체가 신세대(New Space)의 객체를 가리키는 포인터를 가지게 될 경우, 마이너 GC가 이를 인식하지 못해 활성 객체를 지우는 것을 방지하기 위해 '쓰기 장벽(Write barriers)'을 사용합니다 [23-25]. 이 장벽은 구세대에서 신세대로 향하는 포인터(Old-to-new [[Reference|Reference]]s)가 기록될 때 이를 스토어 버퍼(Store buffer)에 저장하여, 이후 마이너 GC 시 이전 세대 전체를 스캔하지 않고도 효율적으로 객체를 수집할 수 있게 합니다 [23, 24].

## ⚖️ Trade-offs & Caveats
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

---

- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.

## 🔗 Knowledge Connections
- **Related Topics:** [[New Space(Young Generation)|New Space(Young Generation]], Major GC, Mark-Sweep-Compact, [[Garbage Collection|Garbage Collection]]
- **Projects/Contexts:** [[V8 Engine|V8 Engine]] Memory [[Management|Management]], Node.js Performance Tuning
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.

---
*Last updated: 2026-04-19*

---

---

- **Related Topics:** New Space (Young Generation), Major GC (Mark-Sweep / Mark-Compact), Write Barriers, [[Generational Hypothesis|Generational Hypothesis]]
- **Projects/Contexts:** [[V8 JavaScript Engine|V8 JavaScript Engine]], [[Orinoco|Orinoco]] Garbage Collector
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다. (소스 전반에서 이전 세대 관리에 대한 설명은 일관되며 명시적인 모순점은 존재하지 않습니다.)

---
*Last updated: 2026-04-19*

---