[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,105 +2,171 @@
|
||||
id: wiki-2026-0508-가비지-컬렉션-garbage-collection
|
||||
title: 가비지 컬렉션 (Garbage Collection)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-51196C]
|
||||
aliases: [GC, Garbage Collection, 메모리 관리]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [gc, memory, runtime, jvm, v8]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 가비지 컬렉션 ([[Garbage Collection]])"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: Java/JS/Go
|
||||
framework: JVM/V8/Go-runtime
|
||||
---
|
||||
|
||||
# [[가비지 컬렉션 (Garbage Collection)]]
|
||||
# 가비지 컬렉션 (Garbage Collection)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가비지 컬렉션(GC)은 애플리케이션에서 더 이상 필요하지 않거나 도달할 수 없는 객체가 차지한 메모리 영역을 식별하고 자동으로 회수하여 재사용할 수 있도록 하는 메모리 관리 프로세스입니다 [1, 2]. 프로그래머가 직접 메모리를 할당하고 해제해야 하는 복잡성을 줄여주고 메모리 누수와 같은 오류를 방지하는 데 도움을 줍니다 [3]. 하지만 메모리 관리에 대한 통제권을 잃게 되며, 시스템 실행을 멈추게 하는 예측 불가능한 일시 정지([[Stop-the-world]])를 유발할 수 있는 양날의 검과 같은 특성을 가집니다 [2-4].
|
||||
## 매 한 줄
|
||||
> **"매 도달 불가능 (unreachable) 한 객체를 자동으로 회수하는 runtime memory manager"**. 1959 LISP의 mark-and-sweep 부터 현대의 ZGC/Shenandoah/G1 까지 — 매 generational + concurrent + region-based 방향으로 진화. 매 sub-millisecond pause 의 실용화 (2024+).
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **도달 가능성(Reachability)과 생존 객체 식별**
|
||||
가비지 컬렉터는 '도달 가능성'을 객체 생존의 지표로 사용합니다 [5]. 전역 객체, 로컬 변수(스택), 웹 브라우저의 DOM 요소 등과 같은 루트(Root) 객체이거나, 다른 생존 객체로부터 참조(Pointer) 체인을 통해 도달할 수 있는 객체는 '생존(live)' 상태로 간주됩니다 [1, 6, 7]. 반면 루트에서 도달할 수 없는 모든 객체는 '죽은(dead)' 객체, 즉 가비지로 분류되어 메모리가 회수됩니다 [1, 6, 8, 9].
|
||||
## 매 핵심
|
||||
|
||||
- **세대별 가설과 힙(Heap) 메모리 구조**
|
||||
대부분의 객체는 생성된 직후 금방 죽는다는 '세대별 가설([[Generational Hypothesis]])'에 기반하여, V8과 같은 최신 엔진은 힙 메모리를 여러 세대로 분할합니다 [10-12]. 객체는 처음 매우 작고 할당이 빠른 '젊은 세대(Young Generation/New-space)'에 할당되며, 이곳에서 여러 번의 가비지 컬렉션 주기를 살아남은 객체만이 크기가 큰 '오래된 세대(Old Generation/Old-space)'로 승격(Promotion)됩니다 [10, 11, 13, 14].
|
||||
### 매 GC 의 근본 작업
|
||||
- **Mark**: GC root (stack, globals, registers) 부터 reachable graph traversal.
|
||||
- **Sweep / Compact / Copy**: unreachable 객체의 회수 + 매 fragmentation 의 처리.
|
||||
|
||||
- **마이너 GC (Minor GC / [[Scavenge]] 연산)**
|
||||
젊은 세대의 메모리를 관리하기 위해 Scavenge(또는 Copy forward) 알고리즘이 자주 그리고 빠르게 실행됩니다 [15-18]. 이 알고리즘은 공간을 두 개의 동일한 반공간(From-space와 To-space)으로 나누어, 생존한 객체를 To-space로 복사하거나 오래된 세대로 승격시킨 후, From-space 전체를 비워버립니다 [15, 19-22]. 이 과정에서 객체들이 연속된 공간에 압축되므로 메모리 파편화가 방지됩니다 [15, 20, 21].
|
||||
### 매 주요 알고리즘
|
||||
- **Mark-and-Sweep**: 매 simple, 매 fragmentation 발생.
|
||||
- **Mark-Compact**: 매 sweep 후 live object 의 compact — fragmentation X.
|
||||
- **Copying (Cheney)**: 매 from-space → to-space 의 live copy. 매 generational young gen 에 사용.
|
||||
- **Generational**: 매 weak generational hypothesis — 매 young die young. 매 young gen frequent + old gen rare.
|
||||
- **Concurrent / Incremental**: 매 mutator thread 와 동시 실행 — pause 의 최소화.
|
||||
- **Region-based (G1, ZGC, Shenandoah)**: 매 heap 의 region 분할 — 매 partial collection.
|
||||
|
||||
- **메이저 GC ([[Major GC]] / [[Mark-Sweep]]-Compact)**
|
||||
오래된 세대를 수집할 때는 Mark-Sweep 및 Mark-Compact 알고리즘이 사용됩니다 [5, 23, 24].
|
||||
* **마킹(Marking):** GC가 루트부터 객체 그래프를 깊이 우선 탐색(DFS)으로 추적하여 생존 객체를 식별합니다. 이때 객체는 발견 상태에 따라 흰색(미발견), 회색(발견되었으나 이웃 미처리), 검은색(완전 처리됨)으로 표시됩니다 [7, 25-27].
|
||||
* **스윕(Sweeping):** 마킹되지 않은 죽은 객체의 범위를 스캔하여 빈 공간(Free list)으로 변환하고 회수합니다 [27-29].
|
||||
* **압축(Compacting):** 메모리 파편화를 줄이기 위해 살아남은 객체들을 조각난 페이지에서 다른 페이지의 빈 공간으로 이주(Migration)시켜 모아줍니다 [2, 27, 30, 31].
|
||||
### 매 응용
|
||||
1. JVM (G1 default since Java 9, ZGC production since Java 17, Shenandoah).
|
||||
2. V8 (Orinoco — concurrent + parallel + incremental).
|
||||
3. Go (concurrent tri-color mark-sweep, sub-ms pause).
|
||||
4. .NET CLR (generational + LOH).
|
||||
5. CPython (reference counting + cycle detector).
|
||||
|
||||
- **성능 최적화 기법 (지연 최소화)**
|
||||
과거 전통적인 GC 방식은 전체 애플리케이션 실행을 멈추는 'Stop-The-World' 일시 정지가 길어지는 문제가 있었습니다 [2, 32]. 이를 개선하기 위해 V8의 [[Orinoco]] 가비지 컬렉터 등은 메인 스레드와 헬퍼 스레드가 동시에 작업을 나누어 수행하는 **병렬(Parallel)** 처리, 메인 스레드의 [[JavaScript]] 실행 사이사이에 GC 작업을 작은 단위로 쪼개서 수행하는 **점진적(Incremental)** 처리, 그리고 메인 스레드 실행을 방해하지 않고 백그라운드에서 GC를 동시에 수행하는 **동시(Concurrent)** 기법을 도입하여 지연(Latency)과 버벅거림을 획기적으로 줄였습니다 [33-38].
|
||||
## 💻 패턴
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
### Tri-color Marking (concurrent GC 의 기반)
|
||||
```python
|
||||
# Tri-color invariant: White (unmarked), Gray (marked, children pending), Black (done)
|
||||
WHITE, GRAY, BLACK = 0, 1, 2
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** 메모리 누수 ([[memory]] Leak), 힙 메모리 (Heap Memory), V8 엔진 ([[V8 Engine]]), [[Stop-The-World]]
|
||||
- **Projects/Contexts:** V8 Orinoco 프로젝트, Node.js, IBM E[[CLIP]]se OpenJ9
|
||||
- **Contradictions/Notes:** 가비지 컬렉션은 프로그래머에게서 수동 메모리 관리에 대한 부담을 덜어주어 대규모 애플리케이션의 메모리 누수나 오류를 획기적으로 줄여주는 장점이 있지만, 메모리 관리 시점에 대한 제어권을 잃게 되며 C/C++ 같은 언어와 비교할 때 포인터를 식별하고 마킹하는 등 런타임 오버헤드를 발생시킨다는 단점도 공존합니다 [3, 4].
|
||||
|
||||
---
|
||||
*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
|
||||
def tri_color_mark(roots, heap):
|
||||
for obj in heap:
|
||||
obj.color = WHITE
|
||||
gray_set = set()
|
||||
for r in roots:
|
||||
r.color = GRAY
|
||||
gray_set.add(r)
|
||||
while gray_set:
|
||||
obj = gray_set.pop()
|
||||
for child in obj.refs:
|
||||
if child.color == WHITE:
|
||||
child.color = GRAY
|
||||
gray_set.add(child)
|
||||
obj.color = BLACK
|
||||
# White = unreachable -> sweep
|
||||
return [o for o in heap if o.color == WHITE]
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Write Barrier (concurrent GC 의 invariant 유지)
|
||||
```c
|
||||
// Dijkstra-style: black -> white write 발생 시 child를 gray로 승격
|
||||
void write_barrier(Object* parent, Object** field, Object* new_val) {
|
||||
if (parent->color == BLACK && new_val && new_val->color == WHITE) {
|
||||
new_val->color = GRAY;
|
||||
gray_queue_push(new_val);
|
||||
}
|
||||
*field = new_val;
|
||||
}
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Generational Allocation (bump allocator)
|
||||
```rust
|
||||
struct YoungGen { start: *mut u8, top: *mut u8, end: *mut u8 }
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
impl YoungGen {
|
||||
fn alloc(&mut self, size: usize) -> Option<*mut u8> {
|
||||
unsafe {
|
||||
let new_top = self.top.add(size);
|
||||
if new_top > self.end { return None; } // trigger minor GC
|
||||
let p = self.top;
|
||||
self.top = new_top;
|
||||
Some(p)
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Reference Counting + Cycle Detection (CPython)
|
||||
```python
|
||||
class Obj:
|
||||
def __init__(self):
|
||||
self.refcount = 1
|
||||
def incref(self): self.refcount += 1
|
||||
def decref(self):
|
||||
self.refcount -= 1
|
||||
if self.refcount == 0:
|
||||
for child in self.refs: child.decref()
|
||||
free(self)
|
||||
# Cycle: a.refs=[b], b.refs=[a] -> refcount 영원히 >0 -> cycle collector 필요
|
||||
```
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
### Finalizer (resource cleanup, careful)
|
||||
```java
|
||||
// Java AutoCloseable + try-with-resources >>> finalize() (deprecated in Java 9+)
|
||||
try (var conn = DriverManager.getConnection(url)) {
|
||||
// use conn
|
||||
} // auto-close, deterministic
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Soft / Weak / Phantom Reference
|
||||
```java
|
||||
WeakReference<Cache> ref = new WeakReference<>(cache);
|
||||
// GC가 free하면 ref.get() == null. Cache 구현에 자주 사용
|
||||
```
|
||||
|
||||
### G1 / ZGC tuning (JVM)
|
||||
```bash
|
||||
java -XX:+UseZGC -Xmx16g -XX:+UseLargePages MyApp
|
||||
# ZGC: <1ms pause, multi-TB heap (Java 21+)
|
||||
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 MyApp
|
||||
# G1: pause-target driven, default since Java 9
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Low-latency service (<10ms p99) | ZGC, Shenandoah, Go GC |
|
||||
| Throughput batch | Parallel GC (JVM), G1 |
|
||||
| Embedded / no-GC | Rust, C++ RAII |
|
||||
| Predictable real-time | No GC + arena allocator |
|
||||
| Reference cycles 빈번 | tracing GC > refcount |
|
||||
|
||||
**기본값**: 매 modern JVM 의 **G1** (or ZGC for >4GB heap), Go 의 **default concurrent collector**.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[메모리 관리]] · [[Runtime Systems]]
|
||||
- 변형: [[Generational GC]] · [[Concurrent GC]] · [[Reference Counting]]
|
||||
- 응용: [[JVM Internals]] · [[V8 Engine]] · [[Go Runtime]]
|
||||
- Adjacent: [[Memory Leak]] · [[Heap]] · [[Stack vs Heap]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: GC tuning, OOM 분석, GC log 해석, allocation pattern 최적화.
|
||||
**언제 X**: 매 hot loop allocation 미세조정 — profiler (async-profiler, pprof) 가 우선.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **System.gc() 호출**: hint 일 뿐, full GC 강제로 pause 유발.
|
||||
- **finalize() 의존**: 매 deprecated. AutoCloseable 사용.
|
||||
- **Large object 의 young gen 할당 가정**: TLAB overflow → tenuring promotion 발생.
|
||||
- **WeakReference cache 의 무한 신뢰**: 매 GC pressure 시 즉시 회수 — cold start.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Jones et al. *The Garbage Collection Handbook* 2nd ed., OpenJDK ZGC docs 2024).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — GC algorithms + tri-color + JVM/Go tuning patterns |
|
||||
|
||||
Reference in New Issue
Block a user