Files

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

4.5 KiB

Raw Blame History

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

title

Orinoco 프로젝트

매 한 줄

"매 V8 의 GC 의 mostly-parallel, mostly-concurrent 의 evolution". 2016 발표된 Orinoco initiative 가 V8 의 stop-the-world phase 를 minimize — incremental marking, parallel scavenge, concurrent sweeping, compaction 의 background offload. 2026 현재 V8 12+ 의 default. Main thread pause time 이 100ms+ → sub-10ms 로 reduce.

매 핵심

매 design pillars

Parallelism: 동시 main thread 를 멈추고 worker thread 다수 사용 (parallel scavenge, parallel compaction).
Concurrency: main thread 는 mutator 의 user code 실행, GC thread 가 background marking/sweeping.
Incremental: long pause 를 작은 step 으로 split, frame 사이 의 짤끔.
Idle-time GC: main thread idle window (rAF gap) 의 활용.

매 collector phases

Young (Scavenger): parallel copying, 보통 <1ms.
Old marking: incremental + concurrent (mutator 동시 실행).
Old sweeping: concurrent free-list rebuild.
Old compaction: parallel evacuation, 매 page-level.
Write barrier: 매 mutator 가 mark 와 race 의 prevent.

매 응용

Chrome / Edge / Brave (V8 host).
Node.js / Deno / Bun (runtime GC 의 같은 Orinoco 기반, Bun 은 JSC 라 다름).
Electron, VS Code (V8 backend).

💻 패턴

Orinoco trace 보기

node --trace-gc --trace-gc-verbose app.js
# [Mark-Compact (incremental) ...]
# [Scavenge (parallel) ...]

Heap stats with v8 module

const v8 = require('v8')
const stats = v8.getHeapStatistics()
console.log({
  used: stats.used_heap_size,
  total: stats.total_heap_size,
  limit: stats.heap_size_limit,
})
const spaces = v8.getHeapSpaceStatistics()
spaces.forEach(s => console.log(s.space_name, s.space_used_size))

Triggering Orinoco-friendly allocation

// O — short-lived 의 young space 에 머무름
function processBatch(items) {
  return items.map(i => ({ id: i.id, val: i.val * 2 }))  // returns die fast
}

// X — large pre-allocated buffer 의 old promotion 강제
const giant = new Array(1e7).fill(0)  // bypasses young entirely

--max-old-space-size tuning

node --max-old-space-size=4096 app.js  # 4GB old space ceiling

Idle-time GC hint

// Chrome internal — webpages cannot directly trigger,
// but rAF-aligned work 의 GC 가 idle gap 을 활용
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0 && tasks.length) doWork(tasks.pop())
})

Heap snapshot diff

const v8 = require('v8'); const fs = require('fs')
v8.writeHeapSnapshot('before.heapsnapshot')
runWorkload()
v8.writeHeapSnapshot('after.heapsnapshot')
// Chrome DevTools → Memory → Comparison

매 결정 기준

상황	Approach
Browser frame budget (16.6ms)	Orinoco 의 default 충분
Large heap (4GB+)	--max-old-space-size + monitoring
Latency-critical (game, RT)	Object pool + young-friendly allocation
Server long-running	--gc-interval + heap dump 주기

기본값: 매 V8 default Orinoco + workload 의 short-lived bias.

🔗 Graph

부모: V8 엔진 힙 아키텍처
변형: Orinoco 가비지 컬렉터
응용: Incremental_Marking · Mark-Sweep-Compact 알고리즘
Adjacent: Garbage Collection · Old_Space · Write Barrier

🤖 LLM 활용

언제: V8 GC 의 internals 설명, Node.js / Chrome heap tuning, --trace-gc 분석. 언제 X: 다른 engine (JSC, SpiderMonkey, Hermes) 의 GC.

❌ 안티패턴

global.gc() 강제: 매 production 의 X. Orinoco 가 의 better job 의 함.
--expose-gc 의 production: 매 attack surface 와 perf degradation.
Heavy sync work: incremental marking 의 main thread 가 idle 해야 진행 → tight loop 의 GC 의 starve.

🧪 검증 / 중복

Verified (V8 blog "Orinoco" 2016, "Concurrent marking" 2017, V8 12.x release notes).
신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — Orinoco design pillars + tracing patterns

4.5 KiB Raw Blame History