Antigravity Agent
8.3 KiB
category, tags, title, last_updated
| category | tags | title | last_updated | ||||
|---|---|---|---|---|---|---|---|
| Unified |
|
|
2026-05-02 |
Incremental Marking
📌 Brief Summary
Incremental Marking은 가비지 컬렉션의 마킹 단계를 한 번의 긴 일시 정지(Stop-the-world)로 처리하지 않고, 애플리케이션 실행과 교차하여 여러 개의 짧은 작업 단위로 나누어 수행하는 메모리 관리 기법입니다 [1, 2]. 이 방식은 가비지 컬렉션에 소요되는 전체 시간을 줄이지는 않지만, 작업을 시간에 따라 분산시킴으로써 메인 스레드의 응답성을 크게 향상시킵니다 [2]. 결과적으로 모바일 기기 등에서 발생할 수 있는 긴 지연을 방지하고 애플리케이션이 사용자 입력 및 애니메이션에 원활하게 반응할 수 있도록 돕습니다 [2, 3].
점진적 마킹(Incremental marking)은 가비지 컬렉션(GC) 과정에서 발생하는 긴 중단 시간(Stop-the-world)을 줄이기 위해 전체 마킹 작업을 여러 개의 작은 일시 정지 구간으로 나누어 실행하는 기법입니다 [1-3]. 애플리케이션의 메인 스레드 실행과 마킹 작업이 교차로 진행되므로 힙 탐색 중에도 사용자 입력 처리나 애니메이션 렌더링을 계속할 수 있습니다 [2, 4]. 비록 가비지 컬렉션에 소비되는 총시간을 줄여주지는 못하지만, 작업 시간을 분산시킴으로써 애플리케이션의 지연 시간(Latency)과 반응성을 크게 개선합니다 [2].
📖 Core Content
-
트리거 및 기본 작동 원리: Incremental Marking은 힙(heap)의 크기가 특정 임계값에 도달할 때 활성화됩니다 [3, 4]. 활성화된 이후에는 애플리케이션이 메모리를 할당할 때마다 짧은 마킹 단계(step)가 실행되어, 객체의 생성 속도에 맞춰 마킹 프로세스가 보조를 맞추게 됩니다 [1, 4]. 일반적인 마킹과 마찬가지로 깊이 우선 탐색(Depth-First-Search) 기반이며, 객체의 상태를 흰색(미발견), 회색(발견되었으나 이웃 객체 미처리), 검은색(완전 처리됨)으로 분류하는 시스템을 사용합니다 [3]. 이 방식을 통해 과거 500
1000ms에 달하던 긴 가비지 컬렉션 지연 시간이 510ms 수준의 매우 짧은 일시 정지로 쪼개집니다 [3, 4]. -
객체 그래프의 동적 변화 및 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)'이 활용됩니다 [8, 9]. 이는 글로벌 마킹 작업을 전체 힙에 걸쳐 점진적으로 수행하며, 부분적인 GC 사이클과 교차되어 긴 정지 시간을 방지합니다 [8].
-
작동 메커니즘 및 활성화 조건: 점진적 마킹은 힙 크기가 특정 임계값에 도달하면 활성화되며, 이후 일정량의 메모리가 할당될 때마다 실행이 잠시 중단되고 점진적 마킹 '단계(step)'가 수행됩니다 [1, 3]. V8 엔진에서는 모바일 기기 기준으로 각 일시 정지 시간이 5~10ms 수준으로 매우 짧게 유지됩니다 [1, 3]. 기본적으로 깊이 우선 탐색(Depth-First-Search) 알고리즘을 사용하며, 객체의 상태를 식별하기 위해 흰색(미발견), 회색(발견되었으나 이웃 미처리), 검은색(완전 처리됨)의 3색 분류 시스템을 사용합니다 [1].
-
객체 그래프 변경과 쓰기 장벽(Write Barriers)의 역할: 점진적 마킹의 가장 큰 특징이자 과제는 마킹이 진행되는 동안 자바스크립트가 실행되어 힙 메모리의 객체 그래프가 지속적으로 변경될 수 있다는 점입니다 [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].
⚖️ Trade-offs & Caveats
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: Programming & Language 분야의 자동 자산화 수행.
- 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- 정책 변화: Programming & Language 분야의 자동 자산화 수행.
🔗 Knowledge Connections
- Related Topics: Garbage Collection, Write Barrier, Lazy Sweeping, Mark-Sweep, Orinoco
- Projects/Contexts: 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), 쓰기 장벽(Write barriers), 지연 스위핑(Lazy sweeping)
- Projects/Contexts: V8 JavaScript Engine, Orinoco Garbage Collector, IBM OpenJ9 (Balanced GC)
- Contradictions/Notes: 점진적 마킹은 메인 스레드의 긴 일시 정지를 방지하고 응답성을 높이는 데에는 훌륭한 기법이지만, 메인 스레드에서 가비지 컬렉션에 소모되는 전체 시간을 줄여주지는 않으며 오히려 미세하게 증가시키는 경향이 있습니다 [2].
Last updated: 2026-04-19