Initial Commit: Reinforced Knowledge Wiki v1.0 - Pure Origin

2026-04-20 14:26:57 +09:00
commit f4e731b115
2141 changed files with 63988 additions and 0 deletions
@@ -0,0 +1,48 @@
+---
+id: P-REINFORCE-AUTO-AABE4C
+category: "[[10_Wiki/💡 Topics/Programming & Language]]"
+confidence_score: 0.90
+tags: [auto-reinforced]
+last_reinforced: 2026-04-20
+github_commit: "[P-Reinforce] Continuous Worker - JavaScript 메모리 관리(JavaScript Memory Management)"
+---
+
+# [[JavaScript 메모리 관리(JavaScript Memory Management)]]
+
+## 📌 한 줄 통찰 (The Karpathy Summary)
+> 지식 요약 정보 추출 중...
+
+## 📖 구조화된 지식 (Synthesized Content)
+**스택(Stack)과 힙(Heap) 메모리 구조**
+*   **스택(Stack):** 실행 중인 프로세스의 정적 데이터(메서드/함수 프레임, 원시 값, 힙 객체에 대한 포인터 등)를 저장하는 영역으로 LIFO 방식으로 관리됩니다 [2-4].
+*   **힙(Heap):** 크기를 컴파일 타임에 결정할 수 없는 동적 데이터 및 객체가 저장되는 공간으로 가비지 컬렉터에 의해 직접 관리됩니다 [3, 10]. V8은 힙을 여러 공간(Space)으로 나눕니다.
+
+**힙의 세대별 구성 (Generational Layout)**
+V8은 객체의 수명을 기준으로 힙을 효율적으로 관리합니다 [6, 7].
+*   **New Space (Young Generation):** 작고 수명이 짧은 대부분의 새 객체가 할당되는 공간입니다 [6, 11-13]. 내부적으로 두 개의 반공간(To-Space와 From-Space)으로 나뉘어 관리됩니다 [14-16].
+*   **Old Space (Old Generation):** New Space에서 일정한 가비지 컬렉션 주기(통상 2회)를 살아남은 객체들이 승격(Promote)되어 이동하는 큰 공간으로, 포인터 영역과 데이터 영역으로 더 나뉩니다 [6, 11, 13, 17, 18].
+*   **기타 영역:** 크기가 제한을 초과하는 객체를 위한 Large Object Space, 실행 가능한 머신 코드가 저장되는 Code Space 등이 존재합니다 [11, 19].
+
+**가비지 컬렉션(Garbage Collection) 메커니즘**
+V8 엔진은 주로 두 가지 가비지 컬렉터를 사용하여 메모리를 회수합니다 [20].
+*   **마이너 GC (Scavenger):** New Space에서 빈번하고 빠르게 동작합니다 [6, 14, 20]. Cheney의 알고리즘에 기반하여 활성 객체를 추적한 뒤 To-Space로 대피(Copy/Evacuate)시키고 기존 From-Space의 쓰레기를 일괄 비워 단편화를 해결합니다 [14, 15, 17].
+*   **메이저 GC (Mark-Sweep-Compact):** Old Space 전체를 관리합니다 [6, 20, 21]. 스택과 전역 객체 같은 루트(Root)에서 출발해 포인터를 따라가며 살아있는 객체를 식별(Mark)하고, 도달할 수 없는 객체의 메모리를 회수(Sweep)한 뒤, 파편화를 줄이기 위해 필요시 객체들을 압축(Compact)합니다 [5, 8, 21-24].
+*   **오리노코(Orinoco):** 최신 V8의 GC 프로젝트로 메인 스레드의 정지 시간(Stop-the-world)을 줄이기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 스레딩 방식을 도입하여 JS 실행과 GC 작업을 효율적으로 교차 수행합니다 [25-31].
+
+**메모리 누수(Memory Leaks)와 최적화**
+*   메모리 누수는 객체가 더 이상 프로그램에서 쓰이지 않음에도 GC 루트(전역 변수, 클로저, 이벤트 리스너, 잊혀진 타이머 등)에서 참조를 계속 유지하여 GC가 수거하지 못할 때 발생합니다 [32-37].
+*   해결 및 탐지 방법으로는 Chrome DevTools의 Heap Snapshot을 사용해 세 번의 스냅샷을 비교하는 기법, Allocation Timeline을 통한 힙 할당 추적, Node.js의 `--trace-gc` 플래그 및 `process.memoryUsage()`를 통한 메모리 상태 모니터링 등이 있습니다 [38-42].
+
+## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
+- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
+- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
+
+## 🔗 지식 연결 (Graph)
+- **Related Topics:** [[Garbage Collection (가비지 컬렉션)]], [[V8 Engine (V8 엔진)]], [[Generational Hypothesis (세대 가설)]], [[Memory Leak (메모리 누수)]]
+- **Projects/Contexts:** [[Chrome DevTools 메모리 분석]], [[Node.js 메모리 튜닝]]
+- **Contradictions/Notes:** 가비지 컬렉션을 사용하는 언어는 메모리 관리의 복잡성을 크게 줄여주지만, 프로그래머가 메모리 제어권을 완전히 상실하게 된다는 단점이 있습니다 [1, 43]. 또한 GC 실행 시 불규칙한 일시 정지 현상이 발생해 대화형 시스템에 영향을 줄 수 있으며 [43], 64비트 플랫폼에서 V8 힙은 포인터 압축(Pointer Compression) 보안 기술로 인해 4GB의 크기 제한(V8 Memory Cage)을 갖는 특징이 있습니다 [44-46].
+
+---
+*Last updated: 2026-04-19*
+- Raw Source: [[00_Raw/2026-04-20/JavaScript 메모리 관리(JavaScript Memory Management).md]]
+---