Prompt Memory Management Compared

# Memory Management Compared 레포지토리 제작 프롬프트

나는 "Memory Management Compared" 레포지토리를 만들려고 해.
이건 **횡단 비교(Synthesis)** 레포야. "메모리를 어떻게 안전하게 회수하는가"라는 한 질문에 여러 런타임이 *서로 다르게* 답한 방식 — JVM GC, V8 Orinoco, Go GC, ART, Swift ARC, Rust 소유권(GC 없음)을 한자리에 놓고 비교한다.
"한 언어의 메모리 관리를 아는 것"과 "GC·ARC·소유권이 같은 문제의 트레이드오프 다른 점이라는 걸 아는 것"의 차이를 만드는 레포다.

## 📋 프로젝트 목표

**컨셉**: "한 런타임의 GC를 아는 것과, 모든 메모리 관리가 '언제 회수하나 + 누가 비용을 치르나'라는 질문에 다르게 답한 것임을 아는 것은 다르다"

**핵심 차별화**:
1. 공통 질문 — 모두 "더 이상 안 쓰는 메모리를 어떻게 안전하게 회수하나"를 푼다
2. 세 가지 답 — 추적 GC(JVM/V8/Go/ART) · 참조 카운팅(Swift ARC) · 소유권(Rust, 런타임 0)
3. 비용의 위치 — 런타임 STW(GC) vs 카운팅 오버헤드(ARC) vs 컴파일 타임 복잡도(Rust)
4. 같은 누수, 다른 약점 — 순환 참조·메모리 누수가 각 모델에서 어떻게 다르게 나타나나

**타겟 독자**:
- 한 언어 GC는 알지만 ARC·소유권과 비교 못하는 개발자
- "GC vs ARC vs Rust"를 정확히 구분 못하는 개발자
- 메모리 누수가 모델마다 어떻게 다른지 모르는 개발자
- 런타임 선택의 메모리 트레이드오프를 알고 싶은 개발자
- 개별 런타임 레포를 마치고 큰 그림을 원하는 개발자

## 🔗 레포 연결

**⬆️ 선행(이 비교의 입력)**:
`jvm-deep-dive`(JVM GC), `v8-engine-deep-dive`(Orinoco GC), `go-deep-dive`(Go GC), `android-runtime-deep-dive`(ART GC), `swift-deep-dive`(ARC), `rust-deep-dive`(소유권).
**🤝 시너지**: `computer-architecture-deep-dive`(메모리 계층·캐시 — 모든 GC 비용의 바닥), `compiler-deep-dive`(소유권·ARC는 컴파일러가 삽입).
**🧬 본질**: 이 레포가 수렴점 — 6개 런타임의 메모리 전략을 하나의 프레임으로.

---

## 🎯 1단계: 전체 구조 설계

> "런타임별"이 아니라 **"질문별"**로 구성, 각 챕터에서 모델을 나란히 비교.

### Chapter 1: 메모리 관리의 근본 문제 (5개 문서)
- 두 가지 질문 — ① 언제 회수가 안전한가(도달 불가) ② 누가 비용을 치르나
- 수동 관리의 문제 — C/C++의 UAF·이중해제·누수, 왜 자동화가 필요한가
- 메모리 계층 — 회수 비용이 캐시·대역폭과 얽히는 지점(computer-architecture 연결)
- 세 가지 접근 — 추적 GC·참조 카운팅·소유권의 개념 소개
- 비교 프레임 — 평가 축(지연·처리량·메모리 오버헤드·결정성·복잡도)

### Chapter 2: 추적 GC — "도달 가능성" (6개 문서)
- 추적의 원리 — 루트에서 도달 가능한 객체만 살리기, 나머지 회수
- 표시-쓸기·복사·압축 — 기본 알고리즘, 단편화 해결
- 세대 가설 — 대부분 객체는 일찍 죽는다, young/old 분리(JVM·V8·ART 공통)
- JVM GC — G1/ZGC, STW 최소화, 힙 영역화(jvm 연결)
- V8 Orinoco — Scavenge + Mark-Compact, 동시·병렬(v8 연결)
- Go GC — 동시 삼색 표시, 세대 없음, 짧은 STW 목표(go 연결)

### Chapter 3: 동시·증분 GC — STW 줄이기 (5개 문서)
- STW 문제 — Stop-The-World가 지연·jank를 만드는 이유(android-performance 연결)
- 삼색 표시 — white/grey/black, 동시 표시의 정확성
- 쓰기 배리어 — 동시 표시 중 변이 처리, 모든 동시 GC의 공통 도구
- ART GC — Concurrent Copying, 모바일 jank 최소화(android-runtime 연결)
- 동시 GC 비교 — JVM ZGC·Go·ART의 STW·처리량 트레이드오프

### Chapter 4: 참조 카운팅 — Swift ARC (5개 문서)
- 참조 카운팅 원리 — 참조 수를 세어 0이면 즉시 해제, 결정적
- ARC — 컴파일러가 retain/release 삽입(swift 연결), GC 스레드 없음
- GC vs ARC — 결정성·메모리 즉시 회수 vs 카운팅 오버헤드·순환 약점
- 순환 참조 — RC의 근본 약점, weak/unowned로 수동 해결
- ARC 비용 — retain/release 빈도, 원자적 카운팅, 최적화

### Chapter 5: 소유권 — Rust (런타임 0) (5개 문서)
- 소유권 모델 — 컴파일 타임에 수명 결정, GC도 RC도 없음(rust 연결)
- RAII — 스코프 종료 시 결정적 해제, drop
- 빌림 검사 — 컴파일 타임에 UAF·이중해제 제거
- Rc/Arc — Rust도 필요시 참조 카운팅, 선택적
- 소유권의 비용 — 런타임 0 대신 컴파일 타임 복잡도(학습·표현 제약)

### Chapter 6: 같은 문제, 다른 약점 (6개 문서)
- 순환 참조 — GC(자동 처리) vs ARC(누수·수동 weak) vs Rust(Rc 순환 주의)
- 메모리 누수 — 각 모델에서 누수가 생기는 다른 방식
- 지연 vs 처리량 — GC의 STW vs ARC의 분산 비용 vs Rust의 예측성
- 메모리 오버헤드 — GC 헤드룸(여유 힙) vs ARC 카운트 필드 vs Rust 최소
- 결정성 — 언제 해제되나(GC 비결정 vs ARC/Rust 결정적)
- 같은 프로그램 비교 — 동일 데이터 구조를 6런타임으로 메모리·지연 측정

### Chapter 7: 트레이드오프 종합 (4개 문서)
- 평가 축 종합 — 지연·처리량·오버헤드·결정성·복잡도 표
- 왜 갈렸나 — 서버(처리량 GC)·모바일(ARC/저지연 GC)·시스템(소유권)의 요구 차이
- 선택의 논리 — 워크로드가 메모리 전략을 결정하는 방식
- 종합 — 메모리 관리 지형도, 새 런타임을 만나도 이 프레임으로 분류

→ **총 36개 문서** 목표.

## 📄 문서 구조

각 문서 10섹션 (표준 v2). 비교가 핵심이라 `🔬`·`📊`에서 *항상 여러 모델을 나란히*. `💻 실전 실험`은 같은 구조를 여러 런타임으로 측정.

## 🎨 스타일 가이드

1. **항상 나란히** — 한 모델만 말하지 말고 GC vs ARC vs 소유권을 같은 축으로
2. **질문으로 환원** — "언제 회수? 누가 비용?"으로 모든 기법 분류
3. **선행 레포로 깊이 위임** — 각 GC 내부는 해당 레포로, 여기선 *비교*
4. **약점을 나란히** — 순환 참조를 6모델에서 어떻게 다루나
5. 트레이드오프 축·삼색 표시·소유권은 다이어그램으로

## 🔬 검증 환경

> polyglot. 같은 데이터 구조를 6런타임으로 측정.