2nd/10_Wiki/Topics/Frontend/Scavenger 알고리즘.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-scavenger-알고리즘	Scavenger 알고리즘	10_Wiki/Topics	verified	self	V8 Scavenger Minor GC Young Generation GC Cheney Algorithm	none	A	0.9	applied	v8 javascript-engine garbage-collection gc performance		2026-05-10	pending	language framework JavaScript V8 / Node.js

Scavenger 알고리즘

매 한 줄

"매 Scavenger 는 V8 의 minor GC — semi-space copying collector for short-lived objects". Cheney's algorithm 기반, young generation (new space) 을 from-space / to-space 로 나눠 매 minor GC 마다 live object 만 to-space 로 복사. Survivor 는 old space 로 promote. 매 fast (수 ms), 매 web app 의 hot path. Major GC (Mark-Sweep-Compact) 와 분리.

매 핵심

매 generational hypothesis

• 대부분 객체는 young 일 때 die → 매 young 만 자주 GC 하면 효율
• V8 heap: new space (young, ~16MB) + old space (long-lived) + large object space + code/map space

매 Cheney's copying

• new space = from-space + to-space (반반)
• minor GC: from-space 의 live root → to-space 로 BFS-copy
• 매 dead object 은 자동 폐기 (sweep 불필요)
• 두번째 survival 시 old space 로 promote

매 비용

• O(live data) — dead 가 많으면 매우 빠름
• pause time: 매 1-5ms (web app)
• write barrier: old → new pointer 추적 (remembered set)

매 응용

1. Allocation-heavy code path 의 GC pressure 분석.
2. Hot loop 에서 전혀 다른 object 양산 회피.
3. Node.js memory profile (--trace-gc).

💻 패턴

Trace GC events

node --trace-gc app.js
# [pid] 12 ms: Scavenge 4.5 (5.7) -> 0.8 (5.7) MB, 0.3 / 0.0 ms
# [pid] 45 ms: Mark-sweep 5.0 (10.2) -> 2.1 (10.2) MB, 4.8 / 0.0 ms

Detailed GC trace

node --trace-gc-verbose --trace-gc-nvp app.js

Heap snapshot (Chrome DevTools 연결)

import { writeHeapSnapshot } from "node:v8";
const file = writeHeapSnapshot();
console.log(`매 snapshot at ${file}`);
// load in DevTools → Memory tab → Compare snapshots

Avoid allocation in hot loop

// 매 BAD — 매 iteration creates objects
function sumPoints(points: { x: number; y: number }[]): number {
  return points
    .map((p) => ({ ...p, sum: p.x + p.y }))  // new objects
    .reduce((a, b) => a + b.sum, 0);
}

// 매 GOOD — 매 no allocation in loop
function sumPointsFast(points: { x: number; y: number }[]): number {
  let s = 0;
  for (let i = 0; i < points.length; i++) s += points[i].x + points[i].y;
  return s;
}

Object pool to bypass GC

class Vec3Pool {
  private pool: { x: number; y: number; z: number }[] = [];
  acquire(x = 0, y = 0, z = 0) {
    const v = this.pool.pop() ?? { x: 0, y: 0, z: 0 };
    v.x = x; v.y = y; v.z = z;
    return v;
  }
  release(v: { x: number; y: number; z: number }) {
    this.pool.push(v);
  }
}
const pool = new Vec3Pool();
const v = pool.acquire(1, 2, 3);
pool.release(v);

Measure GC pause via PerformanceObserver

import { PerformanceObserver } from "node:perf_hooks";

const obs = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(`매 GC ${entry.detail?.kind} took ${entry.duration.toFixed(2)}ms`);
  }
});
obs.observe({ entryTypes: ["gc"], buffered: true });

Tune new space size

node --max-semi-space-size=64 app.js   # default ~16MB, increase for alloc-heavy
node --max-old-space-size=4096 app.js  # old gen

Detect promotion pressure

import v8 from "node:v8";
setInterval(() => {
  const stats = v8.getHeapSpaceStatistics();
  for (const s of stats) {
    console.log(`${s.space_name}: ${(s.space_used_size / 1e6).toFixed(1)} MB`);
  }
}, 5000);

매 결정 기준

상황	Approach
Short-lived 객체 많음 (정상)	Scavenger 가 처리 — 신경 X
Hot loop allocation 폭주	매 reuse / pool / typed arrays
Old space 증가 (leak 의심)	heap snapshot + retainer 분석
Long pause (>50ms)	major GC 문제 — incremental marking 확인
Alloc-heavy server	--max-semi-space-size 증가

기본값: 매 normal code 는 Scavenger 가 자동 처리. 매 hot path 는 alloc-free 하게 작성.

🔗 Graph

• 부모: V8 Engine · Garbage Collection
• 변형: Mark-Sweep-Compact · Incremental_Marking · Concurrent Marking · Orinoco
• 응용: Node.js Performance
• Adjacent: Cheney Algorithm

🤖 LLM 활용

언제: V8 GC 설명, Node.js memory tuning, hot-path optimization. 매 --trace-gc output 해석. 언제 X: 매 일반 web/app code review (premature opt 우려). 매 non-V8 runtime (Bun is JSC fork? actually JSCore — 다른 GC).

❌ 안티패턴

• GC tuning premature: 매 measure 없이 flag 변경. 매 profile 먼저.
• Manual global.gc(): 매 production 에서 --expose-gc 의존 — 매 anti-pattern.
• Object literal in hot loop: GC pressure 증가. 매 reuse / pool.
• Megamorphic shapes: 매 hidden class 변형 → IC miss → 추가 alloc. 매 shape 일정.
• Closures in loop: 매 iteration 마다 closure 생성 → young heap pressure.

🧪 검증 / 중복

• Verified (V8 blog, "Trash talk: the Orinoco garbage collector", 2016 + later updates).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — V8 Scavenger algorithm full content