---
category: Unified
tags: [auto-consolidated, technical-documentation]
title: [[Mark-Sweep|Mark-Sweep]]
last_updated: 2026-05-02
---

# [[Mark-Sweep|Mark-Sweep]]

## 📌 Brief Summary
> Mark-Sweep(마크-스위프)는 V8 엔진과 JVM 등에서 오래된 객체([[Old Space|Old Space]]/Generation)의 메모리를 회수하기 위해 주로 사용되는 가비지 컬렉션(GC) 알고리즘입니다 [1-4]. 이 알고리즘은 힙 메모리 내의 모든 활성 객체를 식별하여 표시하는 '마킹(Marking)' 단계와, 표시되지 않은 죽은 객체의 메모리 영역을 해제하는 '스위핑(Sweeping)' 단계로 동작합니다 [2, 5]. 기존에는 긴 애플리케이션 일시 정지([[Stop-the-world|Stop-the-world]])를 유발했으나, 현대의 엔진들은 점진적(Incremental), 지연(Lazy), 그리고 병행(Concurrent) 처리 기법을 결합하여 성능 오버헤드를 크게 줄였습니다 [6-9].

---

> 마크-스윕(Mark-Sweep)은 V8 엔진 및 자바 가상 머신(JVM) 등에서 더 이상 필요하지 않은 객체의 메모리를 회수하기 위해 사용하는 주요 가비지 컬렉션([[Major GC|Major GC]]) 알고리즘입니다 [1-3]. 이 알고리즘은 힙을 순회하며 활성 상태인 객체를 식별하는 '마크(Mark)' 단계와, 표시되지 않은 객체를 제거하여 메모리를 확보하는 '스윕(Sweep)' 단계로 나뉘어 동작합니다 [2, 4, 5]. 주로 수십에서 수백 메가바이트의 데이터를 포함할 수 있는 대용량 메모리 영역인 구공간([[Old Space|Old Space]])을 관리하는 데 필수적으로 사용됩니다 [4, 6].

## 📖 Core Content
* **마킹(Marking) 단계**
  * 마킹 알고리즘은 본질적으로 포인터로 연결된 객체 그래프를 루트(Roots)에서부터 추적하는 깊이 우선 탐색(Depth-First-[[Search|Search]])입니다 [4, 10, 11].
  * V8 엔진에서는 각 페이지에 할당 가능한 단어(word)당 하나의 비트를 갖는 마킹 비트맵(Marking bitmap)을 유지하며, 객체의 마킹 상태를 세 가지 색상(흰색, 회색, 검은색)으로 분류합니다 [4, 12]. 
  * 흰색(White)은 아직 GC가 발견하지 못한 상태, 회색(Grey)은 발견되었으나 이웃 객체들이 모두 처리되지 않은 상태, 검은색(Black)은 발견되었고 모든 이웃 객체까지 처리가 완료된 활성 상태를 의미합니다 [12, 13].
  * 마킹 과정 중 객체들은 '마킹 데크(Marking deque)'라는 버퍼에 저장되며, 큐가 비워지고 모든 발견된 객체가 검은색으로 표시될 때까지 탐색이 반복됩니다 [10, 13].

* **스위핑(Sweeping) 단계**
  * 마킹이 완료된 후, 스위핑 알고리즘은 힙을 스캔하여 흰색으로 남은 죽은 객체들의 연속된 범위를 찾아냅니다 [4, 14, 15].
  * 확인된 죽은 객체의 메모리 공간을 여유 공간(Free space)으로 변환하고 이를 '자유 목록(Free list)'에 추가하여 새로운 객체 할당 시 재사용할 수 있도록 합니다 [14-16].
  * V8에서는 페이지 수준에서 작동하며, 객체의 크기(소형, 중형, 대형 등)에 따라 별도의 자유 목록을 유지 관리합니다 [14, 16].

* **최적화 및 발전 ([[Optimization|Optimization]])**
  * 전체 힙을 대상으로 하는 마크-스위프는 시간이 오래 걸려 500-1000ms 수준의 'Stop-the-world' 일시 정지를 유발할 수 있었습니다 [6].
  * 이를 완화하기 위해 V8은 힙 마킹을 5-10ms 단위의 작은 작업으로 나누어 실행하는 **점진적 마킹([[Incremental Marking|Incremental Marking]])**과 메모리 해제를 즉시 전부 수행하지 않고 필요에 따라 미루는 **지연 스위핑(Lazy sweeping)**을 도입했습니다 [6, 7, 17, 18].
  * 최근의 [[Orinoco|Orinoco]] 가비지 컬렉터 및 JVM 정책에서는 메인 스레드 실행에 영향을 주지 않기 위해 백그라운드 스레드에서 작업을 수행하는 **병행(Concurrent) 마킹 및 스위핑** 기술을 활용하여 대기 시간을 획기적으로 최소화했습니다 [8, 9, 19].

---

**알고리즘의 주요 동작 단계**
* **마크(Mark) 단계:** 가비지 컬렉터가 스택 포인터와 같은 GC 루트(Root)에서 시작하여 포인터로 연결된 객체 그래프를 깊이 우선 탐색(DFS) 방식으로 재귀적으로 순회합니다 [6, 7]. 이 과정을 통해 도달 가능한(Reachable) 객체, 즉 현재 사용 중인 객체는 활성 상태로 식별되어 마크됩니다 [2, 5, 6, 8]. V8의 마크 단계는 객체의 상태를 미발견 상태인 '백색(White)', 발견되었으나 이웃 객체가 아직 처리되지 않은 '회색(Grey)', 그리고 이웃까지 완전히 처리된 '흑색(Black)'으로 분류하는 삼색(Tri-color) 마킹 시스템을 사용합니다 [6, 9].
* **스윕(Sweep) 단계:** 마크 단계가 완료된 후, 가비지 컬렉터는 힙의 마킹 비트맵을 스캔하여 활성 상태로 흑색 표시가 되지 않은(즉, 백색으로 남은) 객체들의 연속된 범위를 찾습니다 [5, 6, 10, 11]. 이렇게 발견된 사용 불가능한 객체들의 메모리 주소는 여유 공간(Free space)으로 변환되어 빈 목록(Free list)에 추가되며, 이후 새로운 객체를 할당할 때 재사용됩니다 [6, 10, 11].

**V8 엔진에서의 활용 및 성능 최적화**
* **구공간(Old Space) 관리:** 신공간(New Space)을 관리하는 스캐빈지([[Scavenge|Scavenge]]) 알고리즘은 소규모 메모리 수집에는 빠르지만 전체 메모리의 두 배 공간을 필요로 하는 오버헤드가 있어 대용량 힙에는 부적합합니다 [4, 6]. 따라서 V8은 수명이 긴 객체들이 모여 있는 구공간을 수집할 때 마크-스윕 또는 객체를 한곳으로 모으는 과정이 추가된 마크-컴팩트(Mark-Compact) 알고리즘을 사용합니다 [4, 6, 12].
* **동시성 및 점진적 처리 기법:** 전통적인 마크-스윕 방식은 실행 중인 애플리케이션의 메인 스레드를 장시간 멈추게 하는([[Stop-the-world|Stop-the-world]]) 문제가 있습니다 [13, 14]. V8은 이러한 지연 현상을 줄이기 위해 마킹 작업을 여러 번의 짧은 멈춤으로 나누어 수행하는 점진적 마킹([[Incremental Marking|Incremental Marking]]), 백그라운드 헬퍼 스레드를 활용하여 메인 스레드에 영향을 주지 않는 동시적(Concurrent) 마킹 및 스윕, 그리고 필요할 때까지 메모리 해제를 미루는 지연 스윕(Lazy sweeping) 기법을 도입해 성능을 최적화했습니다 [13-16].

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

---

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

## 🔗 Knowledge Connections
- **Related Topics:** [[Garbage Collection|Garbage Collection]], Old Generation, Mark-Compact, [[Incremental Marking|Incremental Marking]], Lazy Sweeping
- **Projects/Contexts:** [[V8 JavaScript Engine|V8 JavaScript Engine]], JVM (Java Virtual Machine), Orinoco Garbage Collector
- **Contradictions/Notes:** 마크-스위프는 빠르고 공간을 효과적으로 재활용하지만, 메모리 파편화(Fragmentation)를 유발할 수 있습니다. 따라서 V8에서는 파편화가 심한 페이지의 라이브 객체를 이동시키고 빈 공간을 병합하는 Mark-Compact 알고리즘과 밀접하게 연계되어 사용됩니다 [2, 4, 5, 20]. 또한, Node.js 환경에서 `--trace_gc` 로그 상에 'Mark-sweep'이 지나치게 자주 발생하거나 반환되는 메모리가 미미하다면 애플리케이션 내 메모리 누수([[memory|memory]] Leak)나 CPU 집약적 블로킹 작업이 존재할 가능성이 높습니다 [21, 22].

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

---

---

- **Related Topics:** 가비지 컬렉션([[Garbage Collection|Garbage Collection]]), 구공간(Old Space), 마크-컴팩트(Mark-Compact), [[점진적 마킹(Incremental marking)|점진적 마킹(Incremental Marking]], 스캐빈지(Scavenge)
- **Projects/Contexts:** V8 엔진([[V8 Engine|V8 Engine]]), 오리노코(Orinoco), [[자바 가상 머신(JVM)|자바 가상 머신(JVM]]
- **Contradictions/Notes:** 소스의 설명에 따르면, 스캐빈지(Scavenge) 알고리즘은 투-스페이스(to-space)와 프롬-스페이스(from-space)를 사용하는 물리적 메모리 오버헤드가 크기 때문에 신공간(New Space)에서만 유용하게 쓰이며, 반면 마크-스윕은 메모리 오버헤드는 적지만 실행 시간이 오래 걸릴 수 있어 구공간(Old Space) 관리에 사용된다는 명확한 역할 분담이 존재합니다 [4, 6].

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

---