Files
2nd/10_Wiki/Topics/DevOps_and_Security/Electron V8 Memory Cage.md
T
Antigravity Agent f8b21af4be Wiki cleanup: error-doc removal, dedup merge, link normalization
10_Wiki/Topics 대규모 정리:
- 오류 캡처/미완성 stub 문서 227개 제거
- 교차폴더 중복 43클러스터 병합 (63파일 → redirect)
- 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건
- 카테고리 MOC 6개 신규 생성
- Graph 섹션 미해결 related-keyword 링크 10,058건 제거

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-20 23:52:15 +09:00

5.2 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-electron-v8-memory-cage Electron V8 Memory Cage 10_Wiki/Topics verified self
V8 Sandbox
V8 Pointer Compression Cage
Electron Memory Limit
none A 0.9 applied
electron
v8
security
memory
sandbox
2026-05-10 pending
language framework
javascript electron

Electron V8 Memory Cage

매 한 줄

"매 V8 의 4GB virtual address cage". 매 V8 의 pointer compression (32-bit offset within 4GB cage) 의 introduction 의 each isolate 의 4GB heap limit 의 hard cap 의 impose. 매 Electron 의 main + renderer + utility process 의 each 의 separate cage 의 hold. 매 2026 년 의 V8 의 sandbox 의 default-on 의 spectre/heap-corruption mitigation 의 standard.

매 핵심

매 cage 구조

  • 4GB virtual region per V8 isolate.
  • 32-bit compressed pointer (relative to cage base).
  • All heap allocations must fit inside cage.
  • External buffer (ArrayBuffer backing) can live outside (with sandbox checks).

매 Electron implication

  • 매 main process: 매 4GB cap.
  • 매 renderer process: 매 4GB cap each (per BrowserWindow).
  • 매 utility process: 매 separate cage.
  • 매 large data → utility process 또는 native module.

매 응용

  1. Heavy LLM inference UI (chunk via utility process).
  2. Video editor (native module for frame buffers).
  3. Multi-window archive viewer (split heaps per window).
  4. Out-of-process computation (worker_threads / utilityProcess).

💻 패턴

Diagnose hitting cage limit

const v8 = require('v8');
const stats = v8.getHeapStatistics();
console.log({
  total_heap_size_mb: stats.total_heap_size / 1024 / 1024,
  heap_size_limit_mb: stats.heap_size_limit / 1024 / 1024,  // ~4GB
  external_memory_mb: stats.external_memory / 1024 / 1024,
});

utilityProcess for off-cage work (Electron 25+)

const { utilityProcess } = require('electron');

const child = utilityProcess.fork(path.join(__dirname, 'heavy-worker.js'), [], {
  serviceName: 'pdf-parser',
  // own V8 cage, own 4GB
});
child.postMessage({ task: 'parse', path: '/big.pdf' });
child.on('message', (result) => { /* handle */ });

worker_thread (lighter, but shares process limits)

const { Worker } = require('worker_threads');

const worker = new Worker('./inference-worker.js', {
  resourceLimits: { maxOldGenerationSizeMb: 3500 }
});
worker.postMessage({ tokens });
worker.on('message', (output) => { /* ... */ });
// NOTE: each worker has its own V8 cage

Native addon for >4GB buffers

// node-addon-api: allocate outside V8 heap
#include <napi.h>
Napi::Value AllocLargeBuffer(const Napi::CallbackInfo& info) {
  size_t bytes = info[0].As<Napi::Number>().Int64Value();
  void* ptr = malloc(bytes);   // outside V8 cage
  // wrap in ArrayBuffer with external backing store
  return Napi::ArrayBuffer::New(info.Env(), ptr, bytes,
      [](Napi::Env, void* data) { free(data); });
}
# Only for dev / specific embedding; loses sandbox + perf
electron --js-flags="--no-pointer-compression" .
# Production: prefer process split

Memory-aware streaming pattern

// Don't load 3GB JSON into V8 — stream + chunk
const { pipeline } = require('stream/promises');
const fs = require('fs');
const { Transform } = require('stream');

await pipeline(
  fs.createReadStream('big.ndjson'),
  new Transform({
    transform(chunk, _, cb) {
      // process chunk — never accumulate full
      cb();
    }
  }),
);

Per-window heap monitor

mainWindow.webContents.on('render-process-gone', (event, details) => {
  if (details.reason === 'oom') {
    log.error('Renderer OOM — likely cage exhausted');
    relaunchWindow();
  }
});

매 결정 기준

상황 Approach
< 1GB working set Single renderer, no special handling
1-3GB Monitor + GC pressure tuning
3-4GB approaching utilityProcess 분리
> 4GB single dataset Native addon + external buffer
Many concurrent heavy ops Multiple utilityProcess (each 4GB)

기본값: 매 utilityProcess 의 split — 매 sandbox + cage 의 multiplication.

🔗 Graph

🤖 LLM 활용

언제: 매 OOM crash diagnosis. 매 cage limit 의 explanation. 매 process-split refactor. 언제 X: 매 V8 internal flag 의 latest 는 V8 release notes 의 verify.

안티패턴

  • Bigger --max-old-space-size only: 매 4GB cap 의 hit. 매 size 만 의 늘림 의 X.
  • Single-renderer 의 모든 work: 매 cage 의 single 의 exhaust. 매 split.
  • External buffer 의 forget GC: 매 native addon 의 finalizer 의 mandatory.

🧪 검증 / 중복

  • Verified (V8 pointer compression docs, Electron process model docs, V8 sandbox RFC).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — V8 cage / Electron process split