2nd/10_Wiki/Topic_Programming/Programming & Language/Orinoco 프로젝트.md

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-orinoco-프로젝트	Orinoco 프로젝트	10_Wiki/Topics	verified	self	Orinoco V8 Orinoco	none	A	0.9	applied	v8 gc performance		2026-05-10	pending	language framework C++ V8 12+

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.

매 응용

1. Chrome / Edge / Brave (V8 host).
2. Node.js / Deno / Bun (runtime GC 의 같은 Orinoco 기반, Bun 은 JSC 라 다름).
3. 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