---
id: [[P-Reinforce|P-Reinforce]]-AUTO-50957B
category: "10_Wiki/💡 Topics/Programming & Language"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - [[Mark-Sweep|Mark-Sweep]]-Compact(메이저 GC)"
---

# [[Mark-Sweep-Compact(메이저 GC)|Mark-Sweep-Compact(메이저 GC]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> Mark-Sweep-Compact(메이저 GC)는 메모리 힙의 전체 영역(주로 Old 세대 공간)에서 더 이상 사용되지 않는 객체를 식별해 메모리를 회수하고 단편화를 해소하는 가비지 컬렉션(GC) 알고리즘입니다 [1-3]. 이 알고리즘은 살아있는 객체를 식별하는 마킹(Marking), 죽은 객체의 메모리를 해제하는 스위핑(Sweeping), 그리고 살아남은 객체들을 한곳으로 모아 메모리 단편화를 줄이는 컴팩팅(Compacting)의 세 가지 핵심 단계로 구성됩니다 [2-4]. 주로 크기가 크고 수명이 긴 객체들이 저장되는 메모리 영역의 효율적인 재사용을 위해 작동합니다 [1, 5, 6].

## 📖 구조화된 지식 (Synthesized Content)
*   **마킹(Marking) 단계**
    *   가비지 컬렉터가 메모리 상에서 도달 가능한(살아있는) 객체를 식별하는 과정입니다 [2, 3]. 
    *   전역 객체나 실행 스택과 같은 루트 객체(Root object)에서 시작하여 참조 포인터를 따라가며 힙 내의 모든 도달 가능한 객체를 재귀적으로 찾아냅니다 [3, 7, 8]. 
    *   V8 엔진에서는 객체의 상태를 흰색(미발견), 회색(발견되었으나 이웃 노드 미처리), 검은색(이웃 노드까지 모두 처리)으로 분류하며 깊이 우선 탐색(DFS) 알고리즘을 사용해 마킹을 수행합니다 [7, 9]. JVM 환경에서는 마크 맵(Mark map)이라는 비트 배열을 이용해 도달 가능한 객체의 위치를 기록합니다 [10].

*   **스위핑(Sweeping) 단계**
    *   마킹 단계를 통해 도달 불가능한 것으로 판별된 죽은 객체들의 메모리 공간을 회수하는 과정입니다 [2, 3, 11].
    *   V8 엔진은 메모리 페이지를 스캔하여 연속된 죽은 객체의 범위를 찾고, 이를 여유 공간으로 변환하여 자유 목록(Free list)에 추가함으로써 새로운 객체 할당 시 재사용될 수 있도록 합니다 [11, 12]. JVM에서도 마크 맵을 분석해 확보 가능한 메모리를 식별하고 자유 목록을 업데이트합니다 [13].

*   **컴팩팅(Compacting) 단계**
    *   스위핑 이후 힙 메모리가 심하게 단편화(Fragmented)되어 있는 경우, 살아있는 객체들을 다른 여유 공간이나 빈 페이지로 마이그레이션하여 메모리 구멍을 없애는 과정입니다 [2, 11, 14, 15].
    *   살아있는 객체를 새 위치로 복사한 뒤, 해당 객체들을 가리키던 모든 포인터(참조)를 새로운 주소로 일일이 업데이트해야 하므로 매우 비용이 큰 작업입니다 [11, 14, 16].
    *   이러한 높은 처리 비용 때문에 매 수집 주기마다 실행되지 않으며, 특정 조건(예: -Xcompactgc 옵션 활성화, 할당할 충분한 여유 공간 부족, 공간 단편화 심화 등)에 따라 선택적이고 제한적으로 수행됩니다 [6, 16, 17].

*   **성능 최적화([[Optimization|Optimization]]) 기법**
    *   메이저 GC의 마크-스위프-컴팩트 작업은 다량의 데이터를 스캔해야 하므로 애플리케이션의 실행을 긴 시간 동안 멈추게([[Stop-the-world|Stop-the-world]]) 할 수 있습니다 [2, 18]. 
    *   이를 방지하고 지연 시간(Latency)을 최소화하기 위해, V8의 최신 GC([[Orinoco|Orinoco]]) 및 특정 JVM 정책은 작업을 여러 번 나누어 수행하는 점진적 마킹([[Incremental Marking|Incremental Marking]])과 힙 페이지의 청소를 지연시키는 지연 스위핑(Lazy sweeping) 기법을 사용합니다 [18-21].
    *   더 나아가 애플리케이션의 메인 스레드와 여러 헬퍼 스레드를 동시에 활용하는 병렬(Parallel) 및 동시(Concurrent) 처리 기법을 적용하여 전체 애플리케이션의 일시 정지 시간을 획기적으로 줄이고 있습니다 [22-25].

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

## 🔗 지식 연결 (Graph)
- **Related Topics:** [[Garbage Collection|Garbage Collection]], Old Generation/Space, memory Fragmentation, [[Incremental Marking|Incremental Marking]]
- **Projects/Contexts:** [[V8 Engine|V8 Engine]] ([[JavaScript|JavaScript]]), JVM (Java Virtual Machine), Orinoco Garbage Collector
- **Contradictions/Notes:** 소스 자료 전반에 걸쳐 큰 모순은 존재하지 않습니다. 다만, 컴팩팅(Compacting) 작업은 메모리 파편화를 완전히 해결하는 훌륭한 방법이지만 V8과 JVM 두 환경 모두에서 매우 무겁고 값비싼(expensive) 동작으로 공통되게 취급되며, 항상 실행되지 않고 철저한 휴리스틱이나 임계조건에 의해 선택적으로 발동된다는 점이 강조됩니다 [6, 16, 17].

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

---
