[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,145 +2,174 @@
|
||||
id: wiki-2026-0508-v8-엔진-힙-아키텍처
|
||||
title: V8 엔진 힙 아키텍처
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [V8 Heap Architecture, V8 메모리 관리, Orinoco, V8 GC]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-consolidated, technical-documentation]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [v8, javascript, gc, memory-management, runtime]
|
||||
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: C++/JavaScript
|
||||
framework: V8 (Chrome/Node.js)
|
||||
---
|
||||
|
||||
# [[V8 엔진 힙 아키텍처 및 로그 분석|V8 엔진 힙 아키텍처 및 로그 분석]]
|
||||
# V8 엔진 힙 아키텍처
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> V8 엔진 힙 아키텍처는 효율적인 메모리 할당과 빠른 가비지 컬렉션(GC)을 위해 물리적 메모리를 세대와 용도별 여러 공간으로 세분화하여 관리하는 구조입니다. 이 시스템은 대부분의 객체가 짧은 시간 안에 소멸한다는 '세대 가설([[Generational Hypothesis|Generational Hypothesis]])'을 바탕으로 설계되어 젊은 세대와 오래된 세대에 각각 다른 알고리즘을 적용합니다. 런타임 로그 분석은 `--trace-gc` 등의 플래그를 활용해 메모리 할당 실패 원인, 수집에 소요된 시간, 힙의 생존 객체 크기 변화를 추적함으로써 메모리 누수와 성능 병목을 진단하는 핵심 기술입니다.
|
||||
## 매 한 줄
|
||||
> **"매 generational + concurrent + parallel + incremental GC — Young (Scavenger) + Old (Mark-Sweep-Compact) + Orinoco pipeline 으로 매 main-thread pause 의 ms 단위로 압축"**. 매 Google V8 (Chrome/Node.js/Deno/Edge) 의 메모리 관리. 매 Orinoco (2016~) 프로젝트 의 GC 의 90%+ off-main-thread. 매 2026 의 V8 12.x 의 production state.
|
||||
|
||||
---
|
||||
## 매 핵심
|
||||
|
||||
> V8 엔진의 힙 아키텍처는 런타임 시 크기나 수명을 미리 알 수 없는 동적 데이터와 자바스크립트 객체들을 저장하고 관리하기 위해 구성된 메모리 구조입니다 [1-3]. 효율적인 가비지 컬렉션을 위해 대부분의 객체가 생성 직후 죽는다는 '세대적 가설([[Generational Hypothesis|Generational Hypothesis]])'을 기반으로 설계되었습니다 [4-6]. 이를 위해 힙은 객체의 수명과 특성에 따라 여러 개의 특수 공간(Space)으로 나뉘며, 각 공간은 페이지(Pages) 단위로 나뉘어 메모리 할당 및 회수에 최적화된 고유의 방식으로 관리됩니다 [7-10].
|
||||
### 매 Heap 구조
|
||||
- **New Space (Young Generation)**: 매 1-8MB. 매 short-lived objects. 매 Scavenger (Cheney's copying) 으로 collect.
|
||||
- From-space + To-space (semi-space). 매 alloc 의 from-space pointer bump.
|
||||
- Scavenge: live objects 의 to-space 로 copy → swap. 매 두 번 survive 한 object 는 Old Space 로 promote.
|
||||
- **Old Space**: 매 long-lived objects. 매 Mark-Sweep-Compact 으로 collect. 매 Major GC.
|
||||
- **Large Object Space**: 매 ≥256KB objects (large arrays, strings). 매 직접 alloc, no copy.
|
||||
- **Code Space**: 매 JIT-compiled code (TurboFan, Maglev, Sparkplug).
|
||||
- **Map Space**: 매 hidden classes (V8 Maps) — object shape descriptors.
|
||||
- **Read-Only Space**: 매 immutable singletons (true, false, null, undefined).
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**V8 힙 메모리 구조 (Heap Organization)**
|
||||
* **Resident Set 분할:** V8 프로세스가 할당받은 메모리는 주로 정적 데이터와 실행 프레임을 담는 스택(Stack) 공간과, 동적 객체가 저장되며 가비지 컬렉션의 대상이 되는 힙(Heap) 공간으로 나뉩니다 [1-3].
|
||||
* **New Space (Young Generation):** 새로 생성된 객체들이 할당되는 작고 빠른 공간입니다. 이 공간은 크기가 1~64MB 정도로 작으며, 내부적으로 'From-Space'와 'To-Space'라는 두 개의 동일한 크기의 반공간(semi-space)으로 나뉘어 [[Scavenge|Scavenge]]r 알고리즘에 의해 관리됩니다 [4-7].
|
||||
* **[[Old Space|Old Space]] (Old Generation):** New Space에서 두 번의 GC를 거치고도 살아남은 객체들이 승격(Promotion)되어 이동하는 공간입니다. 이 공간은 다른 객체를 참조하는 포인터를 가진 'Old Pointer Space'와 문자열 등 순수 데이터만 가진 'Old Data Space'로 세분화되어 마크-스윕-컴팩트([[Mark-Sweep|Mark-Sweep]]-Compact) 알고리즘으로 관리됩니다 [4, 7-9].
|
||||
* **특수 공간:** 여타 공간의 한계를 초과하는 큰 객체를 위해 메모리를 직접 mmap하는 'Large Object Space', JIT 컴파일된 머신 코드를 저장하는 'Code Space', 그리고 크기가 일정한 내부 구조체(Map, Cell)를 담는 전용 공간들이 존재합니다 [4, 7, 8].
|
||||
* **페이지와 샌드박싱:** 각 공간은 연속된 메모리 청크인 페이지(Page)로 구성됩니다. 기본 1MB 단위였으나 저메모리 기기 최적화를 위해 512KB로 축소되기도 하였습니다 [10-13]. 최신 64비트 V8은 포인터 압축([[Pointer Compression|Pointer Compression]]) 기법을 적용하여 힙 전체를 4GB로 제한된 연속된 '케이지(Cage)' 영역 안에 가두어 관리합니다 [14-16].
|
||||
### 매 Orinoco (modern GC pipeline)
|
||||
- **Concurrent Marking**: 매 main-thread alongside 의 worker threads 의 mark phase 실행. Tri-color invariant (white/grey/black) + write barrier 로 mutator 와 coexist.
|
||||
- **Parallel Sweeping/Compacting**: 매 multiple GC threads 의 simultaneously work.
|
||||
- **Incremental Marking**: 매 marking 의 small chunks 로 split — 매 main thread pause 의 <1ms 로 amortize.
|
||||
- **Lazy Sweeping**: 매 sweep 의 alloc time 의 on-demand.
|
||||
|
||||
**가비지 컬렉션(GC) 메커니즘**
|
||||
* **마이너 GC (Scavenge):** New Space의 할당 포인터가 한계에 달하면(Allocation failure) 트리거됩니다. Cheney 알고리즘을 사용해 활성 객체만 'To-Space' 또는 Old Space로 복사하고, 이전 공간을 통째로 비움으로써 파편화를 없앱니다 [5, 17-19].
|
||||
* **메이저 GC:** Old Space의 객체를 수집합니다. 힙 전체에서 활성 객체를 식별(Mark)하고, 접근 불가 객체를 해제(Sweep)하며, 남은 메모리의 파편화를 줄이기 위해 활성 객체들을 한 곳으로 모읍니다(Compact) [20-23].
|
||||
* **오리노코([[Orinoco|Orinoco]]) 프로젝트:** 메인 스레드가 정지되는 '[[Stop-the-world|Stop-the-world]]' 시간을 최소화하기 위해 병렬(Parallel), 점진적(Incremental), 동시(Concurrent) 스레드 기법을 결합하여 GC 작업을 백그라운드로 분산시킵니다 [24-27].
|
||||
### 매 Hidden Classes + Inline Caches
|
||||
- 매 V8 의 dynamic JS object 의 internally fixed-shape "Hidden Class" 로 represent — 매 property access 의 C++ struct field access 만큼 fast.
|
||||
- 매 IC (Inline Cache) 가 call site 에서 매 last shape 의 cache → 매 monomorphic 의 fast path.
|
||||
|
||||
**로그 분석 (Log [[Analysis|Analysis]])**
|
||||
* **--trace-gc 로깅 분석:** `PID, Isolate, Timestamp ms: Type Used (Total) -> Used (Total) MB, Duration ms, Reason` 형식으로 로그가 출력됩니다. 여기서 Reason 항목이 'allocation failure'인 경우 새로운 객체를 담을 메모리 공간이 부족하여 GC가 강제 실행되었음을 의미하며, 소요 시간(Duration) 지표를 통해 메인 스레드 멈춤 길이를 파악할 수 있습니다 [28-31].
|
||||
* **세부 로그 (--trace-gc-verbose / --trace-gc-nvp):** 각 힙 공간(New, Old, Large Object 등)의 사용량과 시스템에 커밋된 양을 분리하여 상세히 보여줍니다. 만약 메이저 GC 이후에도 Old space의 Used 영역이 점진적으로 계속 증가한다면 전형적인 메모리 누수 증상으로 판단합니다 [30, 32].
|
||||
* **프로파일링 도구 연계:** `--heap-prof` 플래그나 크롬 DevTools의 [[Allocation Timeline|Allocation Timeline]]을 활용해 주기적인 힙 스냅샷을 찍고 분석할 수 있습니다. 할당 후 수집되지 않아 파란색으로 남은 타임라인 막대나, DevTools의 'Retainers' 패널을 역추적함으로써 어떤 루트 객체가 해제되어야 할 메모리를 쥐고 있는지([[Retaining Path|Retaining Path]]s) 정확히 파악 가능합니다 [33-36].
|
||||
### 매 응용
|
||||
1. Node.js backend 의 메모리 leak 의 debugging — heap snapshot, retainer chain.
|
||||
2. Browser tab memory budget 관리 — Chrome DevTools Memory tab.
|
||||
3. Server-side rendering 의 short-lived object 의 polymorphism 회피로 throughput 증가.
|
||||
|
||||
---
|
||||
## 💻 패턴
|
||||
|
||||
* **세대적 힙 분할 (Generational Heap Layout):**
|
||||
* **New-space (Young Generation):** 대부분의 새로운 객체가 처음 할당되는 작고 빠른 공간입니다 [4, 7, 9]. 내부적으로 크기가 동일한 두 개의 반공간(To-Space, From-Space)으로 나뉘며, 스캐빈저([[Scavenge|Scavenge]]r)라 불리는 마이너 가비지 컬렉터(Minor GC)에 의해 관리됩니다 [11-14].
|
||||
* **Old-space (Old Generation):** New-space에서 두 번의 가비지 컬렉션 주기 동안 살아남은 객체들이 승격(Promote)되어 이동하는 공간입니다 [4, 12, 15]. 가비지 컬렉션 시 포인터 추적(Tracing) 단계를 최적화하기 위해, 다른 객체에 대한 포인터를 포함하는 **Old-pointer-space**와 문자열이나 박싱된 숫자처럼 포인터가 없는 순수 데이터만 포함하는 **Old-data-space**로 세분화됩니다 [7, 9, 15]. 이곳은 메이저 가비지 컬렉터([[Mark-Sweep|Mark-Sweep]]-Compact)가 관리합니다 [4, 9, 16].
|
||||
### Heap snapshot in Node.js
|
||||
```javascript
|
||||
const v8 = require('v8');
|
||||
const fs = require('fs');
|
||||
|
||||
* **특수 목적 공간 (Specialized Spaces):**
|
||||
* **Large-object-space:** 다른 공간의 크기 제한(일반적으로 1MB 이상)을 초과하는 큰 객체가 저장되는 공간입니다 [7, 9]. 각 객체는 운영체제로부터 별도의 mmap 영역을 할당받으며, 가비지 컬렉터에 의해 위치가 이동되지 않습니다 [7, 9].
|
||||
* **Code-space:** JIT 컴파일러에 의해 생성된 실행 가능한 기계어 명령어 코드가 저장되는 유일한 실행 가능 메모리 영역입니다 [7, 9].
|
||||
* **Map, Cell, Property-cell Space:** 모두 같은 크기를 가지며 가리키는 객체 종류에 제약이 있는 특정 내부 객체들을 저장하여 메모리 수집을 단순화하는 공간입니다 [7, 9].
|
||||
* **Read Only Space:** 영구적이며 절대 이동하거나 변하지 않는 불변(immutable) 객체들을 저장합니다 [17].
|
||||
|
||||
* **페이지 및 물리적 메모리 관리 (Pages & [[memory|memory]] [[Management|Management]]):**
|
||||
* 각 힙 공간은 '페이지(Pages)'라는 연속된 메모리 청크의 집합으로 구성됩니다 [5, 8, 10].
|
||||
* 페이지는 전통적으로 1MB 크기에 1MB로 정렬되어 있었으나, 저메모리 기기 최적화 및 파편화 감소를 위해 512KB 크기로 축소되는 최적화가 적용되었습니다 [5, 8, 10, 18].
|
||||
* 각 페이지에는 메타데이터와 마킹 비트맵이 있는 헤더가 포함되며, 다른 페이지의 객체를 가리키는 포인터 위치를 추적하기 위한 슬롯 버퍼(기억 집합, Remembered Set)가 존재합니다 [8, 10, 19].
|
||||
|
||||
* **포인터 압축과 메모리 케이지 ([[Pointer Compression|Pointer Compression]] & V8 Memory Cage):**
|
||||
* 64비트 시스템에서 메모리 사용량을 줄이고 보안을 강화하기 위해, V8은 모든 힙 객체를 4GB 크기의 연속적인 '메모리 케이지(Memory Cage)' 구역 내에 가둡니다 [20-22].
|
||||
* 객체의 포인터는 완전한 64비트 주소가 아닌 케이지의 기본 주소(Base Address)로부터의 32비트 오프셋으로 압축되어 저장됩니다 [21, 22]. 이로 인해 힙 메모리는 물리적 RAM의 크기와 무관하게 4GB의 엄격한 상한선을 가집니다 [20, 21].
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
---
|
||||
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[세대 가설(Generational Hypothesis)|세대 가설(Generational Hypothesis]], Scavenger(마이너 GC), Mark-Sweep-Compact(메이저 GC), 오리노코(Orinoco) 프로젝트, [[포인터 압축(Pointer Compression)|포인터 압축(Pointer Compression]]
|
||||
- **Projects/Contexts:** Node.js 프로덕션 메모리 누수 진단, [[Chrome|Chrome]] 렌더러 프로세스 V8 샌드박스 보안
|
||||
- **Contradictions/Notes:** 소스 [37-56]에서는 gencon, balanced 등 IBM E[[CLIP|CLIP]]se OpenJ9의 GC 정책에 대한 내용을 깊이 다루고 있으나, 이는 V8 엔진 고유의 구조가 아니므로 본 V8 아키텍처 중심 분석에서는 배제하였습니다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-19*
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
- **Related Topics:** 가비지 컬렉션([[Garbage Collection|Garbage Collection]]), 세대적 가설(Generational Hypothesis), 스캐빈저(Scavenger), Mark-Sweep-Compact, [[포인터 압축(Pointer Compression)|포인터 압축(Pointer Compression]]
|
||||
- **Projects/Contexts:** Node.js 성능 최적화, Google [[Chrome|Chrome]] 브라우저 메모리 관리, [[Orinoco 가비지 컬렉터|Orinoco 가비지 컬렉터]]
|
||||
- **Contradictions/Notes:** V8은 일반적으로 1MB 단위의 페이지 크기를 사용해 왔으나, 최신 최적화 동향에 따라 메모리 단편화를 줄이고 병렬 압축(Compaction) 효율을 높이기 위해 페이지 크기를 512KB로 축소 조정하는 방식을 병행하여 사용합니다 [5, 8, 18].
|
||||
|
||||
---
|
||||
*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
|
||||
// Trigger heap snapshot
|
||||
const stream = v8.getHeapSnapshot();
|
||||
const file = fs.createWriteStream(`heap-${Date.now()}.heapsnapshot`);
|
||||
stream.pipe(file);
|
||||
// Open in Chrome DevTools → Memory → Load
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Heap statistics
|
||||
```javascript
|
||||
const v8 = require('v8');
|
||||
console.log(v8.getHeapStatistics());
|
||||
// { total_heap_size, used_heap_size, heap_size_limit, ... }
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
console.log(v8.getHeapSpaceStatistics());
|
||||
// per-space: new_space, old_space, code_space, large_object_space, ...
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Force GC (debug only)
|
||||
```bash
|
||||
node --expose-gc app.js
|
||||
```
|
||||
```javascript
|
||||
if (global.gc) {
|
||||
global.gc();
|
||||
console.log(process.memoryUsage());
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### Tune heap size (production Node.js)
|
||||
```bash
|
||||
# 4GB old space
|
||||
node --max-old-space-size=4096 server.js
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
# 64MB young space (default ~16MB)
|
||||
node --max-semi-space-size=64 server.js
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### Avoid hidden-class transitions (perf pattern)
|
||||
```javascript
|
||||
// Bad — hidden class transitions
|
||||
const u1 = {};
|
||||
u1.name = 'a'; u1.age = 1; // shape A → B
|
||||
const u2 = {};
|
||||
u2.age = 1; u2.name = 'a'; // different shape! (order matters)
|
||||
|
||||
// Good — same shape every time
|
||||
function makeUser(name, age) {
|
||||
return { name, age }; // same hidden class
|
||||
}
|
||||
```
|
||||
|
||||
### Heap profiling (allocation sampling)
|
||||
```javascript
|
||||
const inspector = require('inspector');
|
||||
const session = new inspector.Session();
|
||||
session.connect();
|
||||
|
||||
session.post('HeapProfiler.startSampling');
|
||||
// run workload
|
||||
session.post('HeapProfiler.stopSampling', (err, { profile }) => {
|
||||
fs.writeFileSync('profile.heapprofile', JSON.stringify(profile));
|
||||
});
|
||||
```
|
||||
|
||||
### Detect memory leak (retainer)
|
||||
```javascript
|
||||
// Common leak: closure holding large object
|
||||
const cache = new Map();
|
||||
function handler(req) {
|
||||
const huge = loadHuge();
|
||||
cache.set(req.id, () => huge.someMethod()); // closure pins huge
|
||||
}
|
||||
|
||||
// Fix: WeakRef + WeakMap (2026 standard)
|
||||
const cache2 = new WeakMap();
|
||||
function handler2(req) {
|
||||
cache2.set(req, loadHuge()); // GC eligible when req dies
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Action |
|
||||
|---|---|
|
||||
| Node.js OOM (heap limit) | `--max-old-space-size` 증가 + heap snapshot 분석 |
|
||||
| 매 잦은 short-lived object → Major GC pressure | Young space 증가 (`--max-semi-space-size`) |
|
||||
| 매 polymorphic call site (slow) | Object shape 의 stabilize — 매 same constructor + same property order |
|
||||
| 매 Large array (>256KB) | Large Object Space 로 직접 — 매 copy 의 X |
|
||||
| 매 long-running process leak | Heap snapshot + retainer chain — 매 closure / event listener / global Map |
|
||||
|
||||
**기본값**: Production 의 매 `--max-old-space-size=4096` + heap snapshot 의 weekly capture.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[JavaScript Runtime]] · [[Garbage Collection]]
|
||||
- 변형: [[Mark-Sweep-Compact]] · [[Generational GC]] · [[Concurrent GC]]
|
||||
- 응용: [[Node.js Memory Tuning]] · [[Chrome DevTools Memory]] · [[V8 TurboFan]]
|
||||
- Adjacent: [[Hidden Classes]] · [[Inline Cache]] · [[JIT Compilation]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 Node.js memory leak 분석 (heap snapshot retainer), 매 V8 GC tuning flag 추천, 매 hidden class transition 의 detect 및 fix, 매 GC pause 분석 (`--trace-gc`).
|
||||
**언제 X**: 매 다른 JS engine (JSC/SpiderMonkey/Hermes) — 매 다른 GC architecture.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **잦은 `delete`**: 매 hidden class transition trigger → polymorphic IC. 매 `obj.x = undefined` 도 같은 문제. 매 missing values 의 `null` 로 init from start.
|
||||
- **Megamorphic call sites**: 매 4+ shapes 의 같은 call site 의 hit → IC 의 megamorphic fallback (slow path).
|
||||
- **거대 closure**: 매 closure 의 enclosing scope 의 모든 var 의 keep alive — 매 small subset 만 capture (let inside).
|
||||
- **`--max-old-space-size` 의 무한 증가**: 매 leak 의 mask — 매 root cause 의 fix.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (V8 공식 blog v8.dev — Orinoco/Sparkplug/Maglev 시리즈, Node.js docs).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — full V8 heap architecture canonical with Orinoco pipeline and 7 patterns |
|
||||
|
||||
Reference in New Issue
Block a user