[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,177 +2,188 @@
|
||||
id: wiki-2026-0508-garbage-collection
|
||||
title: Garbage Collection
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [GC, Garbage Collector, Memory Management]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [runtime, memory, performance, vm]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: java
|
||||
framework: jvm
|
||||
---
|
||||
|
||||
# [[Garbage Collection(가비지 컬렉션)|Garbage Collection(가비지 컬렉션]]
|
||||
# Garbage Collection
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 가비지 컬렉션(Garbage Collection)은 애플리케이션의 메모리 고갈을 방지하기 위해 더 이상 필요하지 않거나 도달할 수 없는 객체가 차지한 메모리를 자동으로 식별하여 회수하는 프로세스입니다 [1-3]. 이 기술은 프로그래머가 직접 메모리를 관리하는 부담을 덜어주고 메모리 누수와 같은 오류를 줄여주지만, 메모리 정리 작업 중 애플리케이션 실행이 멈추는 '[[Stop-the-world|Stop-the-world]]' 지연을 발생시킬 수 있습니다 [2, 4, 5]. 현대의 가비지 컬렉터들은 이러한 지연 시간을 최소화하기 위해 세대별 힙 구조(Generational Layout)와 병렬 및 동시 처리 알고리즘을 도입하여 성능을 최적화하고 있습니다 [6-8].
|
||||
## 매 한 줄
|
||||
> **"매 unreachable memory를 자동으로 reclaim한다"**. 매 GC는 manual malloc/free의 cognitive burden을 제거 — McCarthy의 Lisp(1959)에서 시작, modern V8/HotSpot/Go의 generational + concurrent collector로 evolution. 2026 trade-off는 매 throughput vs latency vs memory overhead.
|
||||
|
||||
---
|
||||
## 매 핵심
|
||||
|
||||
> 가비지 컬렉션(Garbage Collection, GC)은 사용되지 않는 구형 데이터를 메모리에서 해제하는 자바스크립트 엔진의 메모리 관리 프로세스입니다 [1]. 하지만 Three.js와 같은 실시간 3D 렌더링 환경에서는 빈번한 객체 생성이나 메모리 한계 초과로 인해 가비지 컬렉터가 작동할 경우, 프레임이 일시적으로 멈추는(Stuttering) 심각한 성능 저하가 발생할 수 있습니다 [1-3]. 또한, Three.js는 GPU 자원에 대해 자동으로 가비지 컬렉션을 수행하지 않기 때문에 개발자의 명시적인 메모리 관리가 필수적입니다 [4].
|
||||
### 매 Algorithm 분류
|
||||
- **Mark-and-sweep**: 매 reachable mark → unreachable sweep (fragmentation)
|
||||
- **Copying (semi-space)**: 매 live obj 새 space로 copy (50% memory waste)
|
||||
- **Mark-compact**: 매 mark 후 live obj 한쪽 끝으로 compact
|
||||
- **Reference counting**: 매 ref count 0 즉시 free (cycle 문제)
|
||||
|
||||
---
|
||||
### 매 Generational Hypothesis
|
||||
- **매 most objects die young**: 매 short-lived 95%+
|
||||
- **Young gen** (eden + survivor): 매 frequent, fast minor GC
|
||||
- **Old gen** (tenured): 매 infrequent, expensive major GC
|
||||
- **매 write barrier**: old → young reference tracking
|
||||
|
||||
> 가비지 컬렉션(GC)은 애플리케이션에서 더 이상 필요하지 않거나 도달할 수 없는 객체가 차지한 메모리 영역을 식별하고 자동으로 회수하여 재사용할 수 있도록 하는 메모리 관리 프로세스입니다 [1, 2]. 프로그래머가 직접 메모리를 할당하고 해제해야 하는 복잡성을 줄여주고 메모리 누수와 같은 오류를 방지하는 데 도움을 줍니다 [3]. 하지만 메모리 관리에 대한 통제권을 잃게 되며, 시스템 실행을 멈추게 하는 예측 불가능한 일시 정지([[Stop-the-world|Stop-the-world]])를 유발할 수 있는 양날의 검과 같은 특성을 가집니다 [2-4].
|
||||
### 매 응용
|
||||
1. JVM (G1, ZGC, Shenandoah) — sub-ms pause.
|
||||
2. V8 (Orinoco) — concurrent + parallel + incremental.
|
||||
3. Go (tricolor concurrent) — sub-ms STW pause.
|
||||
4. .NET (Server GC, regions) — generational + LOH.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **생존 객체 식별 원리 (Discovering Reachability)**
|
||||
가비지 컬렉터가 해결해야 할 핵심 문제는 죽은 메모리 영역을 식별하는 것입니다 [1]. 객체의 미래 접근 여부를 완벽히 예측하는 것은 정지 문제(Halting Problem)와 같아 불가능하므로, GC는 스택의 로컬 변수나 글로벌 객체와 같은 '루트(Root) 객체'부터 시작하여 포인터 체인을 통해 도달할 수 있는 객체만을 '생존(Live)' 상태로 근사하여 판단하고, 도달 불가능한 모든 객체를 '가비지(Garbage)'로 간주합니다 [1, 9, 10].
|
||||
## 💻 패턴
|
||||
|
||||
- **세대별 가설과 힙 메모리 구조 (Generational Collection & Heap Organization)**
|
||||
대부분의 객체는 생성 후 얼마 지나지 않아 죽는다는 '세대별 가설([[Generational Hypothesis|Generational Hypothesis]])'을 기반으로, V8과 같은 엔진은 힙 메모리를 세대별로 나누어 관리합니다 [6, 11, 12].
|
||||
* **New Space (Young Generation):** 대부분의 새 객체가 할당되는 작고 빠른 공간입니다 [6, 13]. 주기적으로 마이너 가비지 컬렉션이 빠르게 수행됩니다 [6].
|
||||
* **[[Old Space|Old Space]] (Old Generation):** New Space에서 수행된 가비지 컬렉션을 두 번 살아남은 객체들이 승격(Promotion)되어 이동하는 공간입니다 [6, 14, 15].
|
||||
|
||||
- **마이너 가비지 컬렉션 ([[Scavenge|Scavenge]]r)**
|
||||
Young Generation을 관리하는 고속 알고리즘입니다 [16, 17]. New Space를 'To-Space'와 'From-Space'라는 동일한 크기의 두 반공간(Semi-space)으로 분할하는 Cheney의 알고리즘(Scavenge)을 사용합니다 [16, 18]. 할당 공간이 가득 차면, 활성 객체를 추적하여 빈 공간(To-Space)이나 Old Space로 대피(Evacuate)시키면서 메모리를 압축합니다 [18, 19]. 이후 남은 From-Space의 쓰레기 데이터를 한 번에 비우고 두 공간의 역할을 바꿉니다 [18, 19].
|
||||
|
||||
- **메이저 가비지 컬렉션 ([[Mark-Sweep|Mark-Sweep]]-Compact)**
|
||||
수백 메가바이트의 데이터를 포함할 수 있는 Old Space를 관리하기 위해 메이저 GC는 주로 세 가지 단계를 거칩니다 [20, 21].
|
||||
* **Marking (표시):** 깊이 우선 탐색(DFS)을 통해 힙 내의 활성 객체를 발견합니다 [22]. 객체를 흰색(미발견), 회색(발견되었으나 이웃 객체 미처리), 검은색(발견 및 이웃 처리 완료)의 3색 마킹 상태로 분류하여 추적합니다 [23, 24].
|
||||
* **Sweeping (쓸기):** 마킹되지 않은 죽은 객체의 연속된 메모리 범위를 스캔하여 Free list(여유 공간)로 변환하여 후속 할당에 대비합니다 [24-26].
|
||||
* **Compacting (압축):** 메모리 단편화(Fragmentation)를 줄이기 위해 생존 객체들을 빈 공간으로 마이그레이션합니다 [24, 27, 28]. 이는 비용이 많이 드는 작업이지만 실제 메모리 사용량을 대폭 줄여줍니다 [27, 29].
|
||||
|
||||
- **현대 GC의 성능 최적화 ([[Orinoco|Orinoco]] 등)**
|
||||
수백 밀리초에 달하던 과거의 'Stop-the-world' 일시 정지 현상을 줄이기 위해 현대적인 GC는 다양한 기법을 동원합니다 [30, 31].
|
||||
* **Parallel (병렬 처리):** 메인 스레드와 여러 보조 스레드가 GC 작업을 동시에 분담하여 총 정지 시간을 줄입니다 [32, 33].
|
||||
* **Incremental (점진적 처리):** 자바스크립트 실행 중간중간에 작은 단위로 GC 작업을 번갈아 수행(Interleaving)하여 응답성을 유지합니다 [30, 32, 34].
|
||||
* **Concurrent (동시 처리):** 메인 스레드가 자바스크립트를 계속 실행하는 동안 보조 스레드들이 백그라운드에서 전적으로 Marking 및 Sweeping 작업을 수행합니다 [7, 32, 35].
|
||||
|
||||
---
|
||||
|
||||
* **GPU 자원의 명시적 해제 필요성:** Three.js는 지오메트리, 머티리얼, 텍스처 등의 GPU 자원을 자동으로 가비지 컬렉트하지 않습니다 [4]. 따라서 단일 4K 텍스처가 64MB 이상의 VRAM을 차지하는 등 메모리 누수를 방지하려면, 사용이 끝난 자원은 반드시 `.dispose()` 메서드를 호출하여 명시적으로 GPU 메모리에서 해제해야 합니다 [4].
|
||||
* **프레임 멈춤(GC Pauses) 현상:** `useFrame`과 같은 렌더링 루프 내부에서 객체를 계속 생성하거나, 모바일 기기의 시스템 메모리 한계를 초과하는 무거운 텍스처를 사용하면 가비지 컬렉션이 강제로 트리거되어 프레임 멈춤 현상과 스터터링이 발생합니다 [2, 3].
|
||||
* **동적 버퍼 할당과 [[TypedArray|TypedArray]] 부하:** 대규모 인스턴스 렌더링 환경에서 버퍼 용량을 초과해 동적으로 버퍼를 계속 확장할 경우, 수십 메가바이트 단위의 `TypedArray`가 빈번하게 생성되고 파괴됩니다 [1]. 자바스크립트 엔진이 이 구형 배열 데이터를 해제하는 과정에서 가비지 컬렉터가 작동하여 메인 스레드의 점유 시간을 늘리고 프레임 드랍을 유발합니다 [1, 5].
|
||||
* **객체 풀링(Object [[Pooling|Pooling]])을 통한 GC 부하 완화:** 가비지 컬렉션으로 인한 할당 오버헤드와 멈춤 현상을 방지하기 위해서는, 총알이나 파티클처럼 자주 생성되고 파괴되는 엔티티에 대해 새로운 객체를 생성하는 대신 '객체 풀(Pool)'을 미리 구성하여 재사용하는 방식이 강력히 권장됩니다 [6].
|
||||
|
||||
---
|
||||
|
||||
- **도달 가능성(Reachability)과 생존 객체 식별**
|
||||
가비지 컬렉터는 '도달 가능성'을 객체 생존의 지표로 사용합니다 [5]. 전역 객체, 로컬 변수(스택), 웹 브라우저의 DOM 요소 등과 같은 루트(Root) 객체이거나, 다른 생존 객체로부터 참조(Pointer) 체인을 통해 도달할 수 있는 객체는 '생존(live)' 상태로 간주됩니다 [1, 6, 7]. 반면 루트에서 도달할 수 없는 모든 객체는 '죽은(dead)' 객체, 즉 가비지로 분류되어 메모리가 회수됩니다 [1, 6, 8, 9].
|
||||
|
||||
- **세대별 가설과 힙(Heap) 메모리 구조**
|
||||
대부분의 객체는 생성된 직후 금방 죽는다는 '세대별 가설([[Generational Hypothesis|Generational Hypothesis]])'에 기반하여, V8과 같은 최신 엔진은 힙 메모리를 여러 세대로 분할합니다 [10-12]. 객체는 처음 매우 작고 할당이 빠른 '젊은 세대(Young Generation/New-space)'에 할당되며, 이곳에서 여러 번의 가비지 컬렉션 주기를 살아남은 객체만이 크기가 큰 '오래된 세대(Old Generation/Old-space)'로 승격(Promotion)됩니다 [10, 11, 13, 14].
|
||||
|
||||
- **마이너 GC (Minor GC / [[Scavenge|Scavenge]] 연산)**
|
||||
젊은 세대의 메모리를 관리하기 위해 Scavenge(또는 Copy forward) 알고리즘이 자주 그리고 빠르게 실행됩니다 [15-18]. 이 알고리즘은 공간을 두 개의 동일한 반공간(From-space와 To-space)으로 나누어, 생존한 객체를 To-space로 복사하거나 오래된 세대로 승격시킨 후, From-space 전체를 비워버립니다 [15, 19-22]. 이 과정에서 객체들이 연속된 공간에 압축되므로 메모리 파편화가 방지됩니다 [15, 20, 21].
|
||||
|
||||
- **메이저 GC ([[Major GC|Major GC]] / [[Mark-Sweep|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].
|
||||
|
||||
- **성능 최적화 기법 (지연 최소화)**
|
||||
과거 전통적인 GC 방식은 전체 애플리케이션 실행을 멈추는 'Stop-The-World' 일시 정지가 길어지는 문제가 있었습니다 [2, 32]. 이를 개선하기 위해 V8의 [[Orinoco|Orinoco]] 가비지 컬렉터 등은 메인 스레드와 헬퍼 스레드가 동시에 작업을 나누어 수행하는 **병렬(Parallel)** 처리, 메인 스레드의 [[JavaScript|JavaScript]] 실행 사이사이에 GC 작업을 작은 단위로 쪼개서 수행하는 **점진적(Incremental)** 처리, 그리고 메인 스레드 실행을 방해하지 않고 백그라운드에서 GC를 동시에 수행하는 **동시(Concurrent)** 기법을 도입하여 지연(Latency)과 버벅거림을 획기적으로 줄였습니다 [33-38].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
---
|
||||
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.
|
||||
|
||||
---
|
||||
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[Mark-Sweep|Mark-Sweep]], Scavenger, Stop-the-world, Generational Hypothesis, [[memory|memory]] Leak
|
||||
- **Projects/Contexts:** [[V8 JavaScript Engine|V8 JavaScript Engine]], IBM E[[CLIP|CLIP]]se OpenJ9, Orinoco Garbage Collector
|
||||
- **Contradictions/Notes:** 가비지 컬렉션은 메모리 누수를 대폭 줄여주지만, 프로그래머가 메모리 관리에 대한 전적인 통제권을 잃는다는 단점이 존재합니다(모바일 앱 등에서는 큰 문제점) [4, 5]. 또한 대안으로 거론되는 레퍼런스 카운팅([[Reference|Reference]] Counting) 방식 역시 대규모 객체 그래프의 마지막 참조가 제거될 때 가비지 컬렉션과 유사한 예측 불가능한 정지 현상을 유발할 수 있어 완벽한 대체재는 아닙니다 [5].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
- **Related Topics:** [[Memory Management|Memory Management]], Object Pooling, [[GPU Resources|GPU Resources]]
|
||||
- **Projects/Contexts:** Three.js, [[WebGL|WebGL]]
|
||||
- **Contradictions/Notes:** 소스에 관련 정보가 부족합니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
- **Related Topics:** 메모리 누수 ([[memory|memory]] Leak), 힙 메모리 (Heap Memory), V8 엔진 (V8 Engine), [[Stop-the-world|Stop-The-World]]
|
||||
- **Projects/Contexts:** V8 Orinoco 프로젝트, Node.js, IBM E[[CLIP|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
|
||||
### JVM ZGC 설정 (sub-ms pause)
|
||||
```bash
|
||||
java -XX:+UseZGC \
|
||||
-XX:+ZGenerational \
|
||||
-Xmx16g \
|
||||
-XX:SoftMaxHeapSize=14g \
|
||||
-jar app.jar
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Go GC tuning
|
||||
```go
|
||||
import "runtime/debug"
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
func init() {
|
||||
// 매 GOGC=100 default — 100% growth 시 trigger
|
||||
debug.SetGCPercent(50) // 매 lower = more frequent, less memory
|
||||
|
||||
// 매 hard memory limit (Go 1.19+)
|
||||
debug.SetMemoryLimit(8 << 30) // 매 8GB
|
||||
}
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
// 매 manual hint after large alloc
|
||||
runtime.GC()
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### V8 Heap snapshot (Node.js)
|
||||
```javascript
|
||||
const v8 = require('v8');
|
||||
const fs = require('fs');
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
// 매 heap snapshot for leak analysis
|
||||
const snapshot = v8.writeHeapSnapshot();
|
||||
console.log(`Heap snapshot: ${snapshot}`);
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
// 매 heap statistics
|
||||
console.log(v8.getHeapStatistics());
|
||||
// { total_heap_size, used_heap_size, heap_size_limit, ... }
|
||||
```
|
||||
|
||||
### Reference cycle break (Python)
|
||||
```python
|
||||
import weakref
|
||||
|
||||
class Parent:
|
||||
def __init__(self):
|
||||
self.children = []
|
||||
|
||||
class Child:
|
||||
def __init__(self, parent):
|
||||
# 매 strong cycle: parent ↔ child → leak
|
||||
# self.parent = parent
|
||||
# 매 fix: weakref
|
||||
self.parent = weakref.ref(parent)
|
||||
|
||||
def get_parent(self):
|
||||
return self.parent() # 매 None if collected
|
||||
```
|
||||
|
||||
### Object pooling (avoid GC pressure)
|
||||
```csharp
|
||||
public class BulletPool
|
||||
{
|
||||
private readonly Stack<Bullet> pool = new();
|
||||
|
||||
public Bullet Rent()
|
||||
{
|
||||
if (pool.Count > 0) return pool.Pop();
|
||||
return new Bullet();
|
||||
}
|
||||
|
||||
public void Return(Bullet b)
|
||||
{
|
||||
b.Reset();
|
||||
pool.Push(b);
|
||||
}
|
||||
}
|
||||
// 매 hot path에서 alloc 회피 → minor GC 감소
|
||||
```
|
||||
|
||||
### Tricolor marking (concept, Go-style)
|
||||
```go
|
||||
// 매 white = unscanned, gray = in queue, black = scanned
|
||||
// invariant: 매 black은 white를 직접 reference 안 함
|
||||
// write barrier로 enforce:
|
||||
func writeBarrier(slot **Object, ptr *Object) {
|
||||
if isBlack(slot) && isWhite(ptr) {
|
||||
markGray(ptr) // 매 promote to gray
|
||||
}
|
||||
*slot = ptr
|
||||
}
|
||||
```
|
||||
|
||||
### .NET Span<T> (stack alloc, no GC)
|
||||
```csharp
|
||||
public int SumDigits(int n)
|
||||
{
|
||||
Span<int> digits = stackalloc int[16];
|
||||
int i = 0;
|
||||
while (n > 0) { digits[i++] = n % 10; n /= 10; }
|
||||
int sum = 0;
|
||||
for (int j = 0; j < i; j++) sum += digits[j];
|
||||
return sum; // 매 zero heap allocation
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | GC choice |
|
||||
|---|---|
|
||||
| Low-latency trading (JVM) | ZGC / Shenandoah (sub-ms pause) |
|
||||
| Throughput batch (JVM) | Parallel GC |
|
||||
| Game engine (managed) | Object pooling + GC.Collect at safe points |
|
||||
| Real-time embedded | Manual memory or Rust (no GC) |
|
||||
| Server-side Go | Default tricolor + GOGC tuning |
|
||||
|
||||
**기본값**: 매 modern runtime의 default GC. 매 measure first (allocation profiler), tune later.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Memory Management]] · [[Programming Language Runtime]]
|
||||
- 변형: [[Generational GC]] · [[Concurrent GC]] · [[Reference Counting]]
|
||||
- 응용: [[JVM]] · [[V8]] · [[Go Runtime]] · [[CLR]]
|
||||
- Adjacent: [[Manual Memory Management]] · [[Rust Ownership]] · [[ARC]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 GC pause 분석, allocation hotspot 식별, runtime flag tuning 추천.
|
||||
**언제 X**: 매 Rust/C/C++ — GC 없음. 매 hard real-time — non-deterministic pause unacceptable.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Calling GC.Collect() 빈번**: 매 fragmentation + throughput 손실.
|
||||
- **Finalizer 의존**: 매 non-deterministic, GC overhead 증가 → IDisposable 사용.
|
||||
- **Large object heap thrash**: 매 LOH (.NET) 매번 alloc → fragmentation.
|
||||
- **String concat in loop**: 매 immutable string × N alloc → StringBuilder 사용.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Jones, Hosking, Moss, "The Garbage Collection Handbook", 2nd ed., 2023).
|
||||
- Verified (Oracle ZGC docs, OpenJDK).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — generational GC + V8/Go/JVM modern collectors |
|
||||
|
||||
Reference in New Issue
Block a user