Files
2nd/Programming & Language/Mark-Sweep.md
T

4.6 KiB

id, category, confidence_score, tags, last_reinforced, github_commit
id category confidence_score tags last_reinforced github_commit
P-REINFORCE-AUTO-261A28 10_Wiki/💡 Topics/Programming & Language 0.90
auto-reinforced
2026-04-20 [P-Reinforce] Continuous Worker - Mark-Sweep

Mark-Sweep

📌 한 줄 통찰 (The Karpathy Summary)

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

📖 구조화된 지식 (Synthesized Content)

  • 마킹(Marking) 단계

    • 마킹 알고리즘은 본질적으로 포인터로 연결된 객체 그래프를 루트(Roots)에서부터 추적하는 깊이 우선 탐색(Depth-First-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)

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

⚠️ 모순 및 업데이트 (Contradictions & RL Update)

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

🔗 지식 연결 (Graph)

  • Related Topics: Garbage Collection, Old Generation, Mark-Compact, Incremental Marking, Lazy Sweeping
  • Projects/Contexts: 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 Leak)나 CPU 집약적 블로킹 작업이 존재할 가능성이 높습니다 [21, 22].

Last updated: 2026-04-19

  • Raw Source: 00_Raw/2026-04-20/Mark-Sweep.md