---
id: wiki-2026-0508-incremental-marking
title: Incremental Marking
category: 10_Wiki/Topics
status: needs_review
canonical_id: self
aliases: []
duplicate_of: none
source_trust_level: A
confidence_score: 0.92
tags: [auto-consolidated, technical-documentation]
raw_sources: []
last_reinforced: 2026-05-08
github_commit: pending
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
tech_stack:
  language: unspecified
  framework: unspecified
---

# [[Incremental Marking|Incremental Marking]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> Incremental Marking은 가비지 컬렉션의 마킹 단계를 한 번의 긴 일시 정지([[Stop-the-world|Stop-the-world]])로 처리하지 않고, 애플리케이션 실행과 교차하여 여러 개의 짧은 작업 단위로 나누어 수행하는 메모리 관리 기법입니다 [1, 2]. 이 방식은 가비지 컬렉션에 소요되는 전체 시간을 줄이지는 않지만, 작업을 시간에 따라 분산시킴으로써 메인 스레드의 응답성을 크게 향상시킵니다 [2]. 결과적으로 모바일 기기 등에서 발생할 수 있는 긴 지연을 방지하고 애플리케이션이 사용자 입력 및 애니메이션에 원활하게 반응할 수 있도록 돕습니다 [2, 3].

---

> 점진적 마킹(Incremental marking)은 가비지 컬렉션(GC) 과정에서 발생하는 긴 중단 시간([[Stop-the-world|Stop-the-world]])을 줄이기 위해 전체 마킹 작업을 여러 개의 작은 일시 정지 구간으로 나누어 실행하는 기법입니다 [1-3]. 애플리케이션의 메인 스레드 실행과 마킹 작업이 교차로 진행되므로 힙 탐색 중에도 사용자 입력 처리나 애니메이션 렌더링을 계속할 수 있습니다 [2, 4]. 비록 가비지 컬렉션에 소비되는 총시간을 줄여주지는 못하지만, 작업 시간을 분산시킴으로써 애플리케이션의 지연 시간(Latency)과 반응성을 크게 개선합니다 [2].

## 📖 구조화된 지식 (Synthesized Content)
- **트리거 및 기본 작동 원리:** 
  Incremental Marking은 힙(heap)의 크기가 특정 임계값에 도달할 때 활성화됩니다 [3, 4]. 활성화된 이후에는 애플리케이션이 메모리를 할당할 때마다 짧은 마킹 단계(step)가 실행되어, 객체의 생성 속도에 맞춰 마킹 프로세스가 보조를 맞추게 됩니다 [1, 4]. 일반적인 마킹과 마찬가지로 깊이 우선 탐색(Depth-First-[[Search|Search]]) 기반이며, 객체의 상태를 흰색(미발견), 회색(발견되었으나 이웃 객체 미처리), 검은색(완전 처리됨)으로 분류하는 시스템을 사용합니다 [3]. 이 방식을 통해 과거 500~1000ms에 달하던 긴 가비지 컬렉션 지연 시간이 5~10ms 수준의 매우 짧은 일시 정지로 쪼개집니다 [3, 4].

- **객체 그래프의 동적 변화 및 [[Write Barrier|Write Barrier]] 방어:** 
  점진적 마킹의 가장 큰 난제는 마킹 작업 사이사이에 자바스크립트가 실행되므로 힙 내의 객체 그래프 구조가 계속 변할 수 있다는 점입니다 [2, 5]. 특히 완전히 검사가 끝난 '검은색' 객체에서 아직 발견되지 않은 '흰색' 객체로의 새로운 포인터가 생성될 경우, 살아있는 흰색 객체가 가비지로 잘못 분류될 위험이 있습니다 [5]. V8 엔진은 이를 방지하기 위해 '쓰기 장벽(Write Barrier)'을 사용하여 검은색에서 흰색으로 향하는 포인터 생성을 감지합니다 [5]. 이러한 포인터가 감지되면 해당 검은색 객체를 다시 회색으로 변경하고 마킹 덱(deque)에 밀어넣어 재검색되도록 보장합니다 [5].

- **Lazy Sweeping으로의 전환:** 
  모든 객체의 생존 여부가 식별되어 Incremental Marking 작업이 완료되면, V8은 한꺼번에 메모리를 지우지 않고 필요에 따라 페이지 단위로 메모리를 해제하는 'Lazy Sweeping' 단계를 시작하여 남은 오버헤드를 분산시킵니다 [6, 7].

- **IBM JVM에서의 적용 사례:** 
  자바스크립트 엔진 외에도 IBM JVM의 균형(balanced) GC 정책에서 '점진적 동시 마킹(Incremental concurrent mark [[Processing|Processing]])'이 활용됩니다 [8, 9]. 이는 글로벌 마킹 작업을 전체 힙에 걸쳐 점진적으로 수행하며, 부분적인 GC 사이클과 교차되어 긴 정지 시간을 방지합니다 [8].

---

* **작동 메커니즘 및 활성화 조건:** 
  점진적 마킹은 힙 크기가 특정 임계값에 도달하면 활성화되며, 이후 일정량의 메모리가 할당될 때마다 실행이 잠시 중단되고 점진적 마킹 '단계(step)'가 수행됩니다 [1, 3]. V8 엔진에서는 모바일 기기 기준으로 각 일시 정지 시간이 5~10ms 수준으로 매우 짧게 유지됩니다 [1, 3]. 기본적으로 깊이 우선 탐색(Depth-First-[[Search|Search]]) 알고리즘을 사용하며, 객체의 상태를 식별하기 위해 흰색(미발견), 회색(발견되었으나 이웃 미처리), 검은색(완전 처리됨)의 3색 분류 시스템을 사용합니다 [1].

* **객체 그래프 변경과 쓰기 장벽([[Write Barrier|Write Barrier]]s)의 역할:** 
  점진적 마킹의 가장 큰 특징이자 과제는 마킹이 진행되는 동안 자바스크립트가 실행되어 힙 메모리의 객체 그래프가 지속적으로 변경될 수 있다는 점입니다 [2, 5]. 만약 가비지 컬렉터가 이미 탐색을 마친 '검은색' 객체에서 아직 탐색되지 않은 '흰색' 객체로 새로운 참조가 생성된다면, 살아있는 흰색 객체가 가비지로 잘못 분류될 위험이 있습니다 [5]. V8 엔진은 이를 해결하기 위해 쓰기 장벽(Write barrier)을 활용합니다 [5]. 쓰기 장벽은 검은색 객체에서 흰색 객체로의 포인터 생성을 감지하며, 해당 포인터가 감지되면 검은색 객체를 다시 회색으로 변경하고 마킹 데크(Deque)로 되돌려 보내 흰색 객체가 정상적으로 발견되도록 순서를 보존합니다 [5]. 

* **다른 엔진에서의 구현 (IBM OpenJ9):**
  IBM의 OpenJ9 VM에서는 'Balanced GC 정책'을 통해 점진적 동시 마킹(Incremental concurrent mark)을 지원합니다 [6]. 이 방식은 전역적인 STW(Stop-The-World)를 피하며 전체 힙에 걸쳐 마킹 작업을 점진적으로 수행합니다 [7]. 다른 정책의 동시 마킹과는 달리 애플리케이션 스레드가 객체 추적에 참여하지 않고 오직 백그라운드 스레드만이 객체를 추적하고 카드 테이블 내의 마크 맵(Mark map)을 업데이트하여 객체 변경을 관리합니다 [7].

* **후속 단계 (지연 스위핑):**
  점진적 마킹이 완료되어 힙 내 모든 객체의 생존 여부가 결정되면, 가비지 컬렉터는 지연 스위핑(Lazy sweeping)을 시작합니다 [8, 9]. 메모리를 즉시 한 번에 모두 비우는 대신, 필요할 때마다 필요한 만큼의 페이지를 정리함으로써 GC 주기를 완료하고 다음 점진적 마킹을 준비하게 됩니다 [8, 9].

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

---

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

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Garbage Collection|Garbage Collection]], Write Barrier, Lazy Sweeping, Mark-Sweep, [[Orinoco|Orinoco]]
- **Projects/Contexts:** [[V8 JavaScript Engine|V8 JavaScript Engine]], IBM OpenJ9
- **Contradictions/Notes:** V8 엔진의 Incremental Marking은 메인 스레드가 자바스크립트 실행 중간에 간헐적으로 마킹 작업을 나누어 수행하는 구조이지만 [2], IBM JVM의 Incremental concurrent mark 작업에서는 애플리케이션 스레드가 객체 추적에 관여하지 않으며 오직 백그라운드 스레드만이 사용된다는 기술적 차이가 존재합니다 [8].

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

---

---

- **Related Topics:** 가비지 컬렉션([[Garbage Collection|Garbage Collection]]), 쓰기 장벽(Write barriers), 지연 스위핑(Lazy sweeping)
- **Projects/Contexts:** [[V8 JavaScript Engine|V8 JavaScript Engine]], [[Orinoco|Orinoco]] Garbage Collector, IBM OpenJ9 (Balanced GC)
- **Contradictions/Notes:** 점진적 마킹은 메인 스레드의 긴 일시 정지를 방지하고 응답성을 높이는 데에는 훌륭한 기법이지만, 메인 스레드에서 가비지 컬렉션에 소모되는 전체 시간을 줄여주지는 않으며 오히려 미세하게 증가시키는 경향이 있습니다 [2].

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

---

## 🤖 LLM 활용 힌트 (How to Use This Knowledge)

**언제 이 지식을 쓰는가:**
- *(TODO)*

**언제 쓰면 안 되는가:**
- *(TODO)*

## 🧪 검증 상태 (Validation)

- **정보 상태:** needs_review
- **출처 신뢰도:** A
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*

## 🧬 중복 검사 (Duplicate Check)

- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
- **처리 방식:** UPDATE (자동 정규화)
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

## 🕓 변경 이력 (Changelog)

| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|------|-----------|-----------|--------|
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |

## 💻 코드 패턴 (Code Patterns)

**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*

```text
# TODO
```

## 🤔 의사결정 기준 (Decision Criteria)

**선택 A를 써야 할 때:**
- *(TODO)*

**선택 B를 써야 할 때:**
- *(TODO)*

**기본값:**
> *(TODO)*

## ❌ 안티패턴 (Anti-Patterns)

- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*