Files
2nd/10_Wiki/Topics/DevOps_and_Security/New Space(Young Generation).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.4 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-new-space-young-generation New Space (Young Generation) 10_Wiki/Topics verified self
Young Generation
Eden + Survivor
Scavenger
Minor GC
Nursery
none A 0.95 applied
gc
v8
jvm
generational-gc
memory-management
2026-05-10 pending
language framework
C++ V8, HotSpot JVM, .NET

New Space (Young Generation)

매 한 줄

"매 generational GC 의 short-lived object region". 매 1984 Lieberman & Hewitt 의 매 generational hypothesis ("most objects die young") 매 base. 매 V8 의 New Space (Scavenger), 매 JVM 의 Young Gen (Eden + 2 Survivor), 매 .NET 의 Gen 0/1 — 매 모두 매 동일한 idea: 매 young object 매 cheap copy + 매 old object 매 promote.

매 핵심

매 generational hypothesis

  • 매 90%+ object 매 매 first GC cycle 의 die.
  • 매 survivor 매 long-lived 가능 매 high.
  • 매 separate region + 매 separate algorithm 매 efficient.

매 V8 New Space 구조

  • 매 to-space + from-space (semispace).
  • 매 Cheney's Scavenge (Cheney 1970) — 매 BFS copy.
  • 매 size 매 1-8MB per isolate (V8 12+ adaptive).
  • 매 minor GC: 매 < 1ms typical.
  • 매 promotion: 매 2회 survive 시 Old Space 로 이동.

매 JVM Young Gen 구조

  • 매 Eden (allocation site) + Survivor 0 + Survivor 1.
  • 매 Eden full → 매 minor GC → 매 live → S0 (or S1).
  • 매 매 매 Tenuring threshold (default 15) 도달 → Old Gen.

매 응용

  1. JS engine (V8 / SpiderMonkey / JavaScriptCore).
  2. JVM (HotSpot G1, ZGC, Parallel).
  3. .NET CLR.
  4. Dart VM.
  5. Lua의 incremental (slightly different).

💻 패턴

1. V8 heap snapshot 측정

import v8 from 'node:v8';

const stats = v8.getHeapSpaceStatistics();
const newSpace = stats.find(s => s.space_name === 'new_space');
console.log({
  size: newSpace.space_size,
  used: newSpace.space_used_size,
  available: newSpace.space_available_size,
});

2. V8 GC trace flag

node --trace-gc app.js
# [12345:0x1234] 234 ms: Scavenge 4.5 (5.3) -> 0.8 (5.3) MB, 1.2 ms
node --trace-gc-verbose --max-semi-space-size=64 app.js

3. Allocation site 의 promotion 회피

// 매 hot loop 의 ephemeral 의 ㅇ
function processStream(items: Item[]) {
  for (const item of items) {
    const tmp = { x: item.x * 2, y: item.y * 2 };  // 매 New Space alloc
    emit(tmp);  // 매 die immediately — minor GC 의 reclaim
  }
}

// 매 X — 매 long-lived array 의 promotion
const cache: Record<string, Result> = {};
function bad(item: Item) {
  cache[item.id] = compute(item);  // 매 Old Space promotion
}

4. JVM Young Gen tuning

java -Xms2g -Xmx8g \
     -XX:NewRatio=2 \
     -XX:SurvivorRatio=8 \
     -XX:MaxTenuringThreshold=10 \
     -XX:+UseG1GC \
     -Xlog:gc*:file=gc.log \
     App

5. Pretenuring (object 의 사전 Old 배치)

// V8 internal: AllocationSite 가 매 history 추적 → 매 large/long-lived 매 immediate Old.
// 매 user-facing API X — 매 V8 의 implicit.
// 매 application 의 hint: 매 reuse object pool.

6. Object pool (allocation pressure 회피)

class Vec3Pool {
  private pool: Vec3[] = [];
  acquire(): Vec3 {
    return this.pool.pop() ?? new Vec3();
  }
  release(v: Vec3) {
    v.set(0, 0, 0);
    if (this.pool.length < 1000) this.pool.push(v);
  }
}
// 매 매 frame 의 allocation 의 X → minor GC 매 silent

7. .NET Gen 0 stats

GC.Collect(0);  // 매 Gen 0 (Young) 매 only
Console.WriteLine($"Gen0: {GC.CollectionCount(0)}");
Console.WriteLine($"Gen1: {GC.CollectionCount(1)}");
Console.WriteLine($"Gen2: {GC.CollectionCount(2)}");

매 결정 기준

상황 New Space tuning
Allocation-heavy (web server) 매 large New Space (V8 64-256MB) — 매 Scavenge frequency 줄임
Long-lived state (cache) 매 small New Space — 매 promote fast
Latency-critical (game) 매 object pool + 매 zero-alloc hot path
Memory-tight (mobile) 매 default + GC tuning 의 X
Long debugging session --trace-gc + heap snapshot

기본값: 매 V8 default New Space + 매 hot path 의 object pool 사용.

🔗 Graph

🤖 LLM 활용

언제: 매 GC pause 매 SLO 위협. 매 allocation profiling 매 hot path 식별. 매 V8 / JVM heap behavior 의 understanding. 언제 X: 매 Rust / C++ (no GC). 매 small script (default 면 충분). 매 micro-optimization 의 매 measurement 의 X.

안티패턴

  • 매 frame 의 새 closure: 매 frame 마다 매 object alloc → 매 Scavenge 폭발.
  • Long-lived array 의 매 push/splice: 매 internal buffer 의 New Space alloc → promote.
  • TypedArray 의 매 매 new 만들기: 매 reuse — 매 Float32Array 매 large allocation.
  • 매 GC 의 force (global.gc()): 매 production 의 X — 매 V8 heuristic 의 disrupt.
  • 매 NewRatio 매 production 의 변경 의 측정 없이: 매 application-specific tuning — default 매 first.

🧪 검증 / 중복

  • Verified (V8 design docs 2026-05, OpenJDK HotSpot source, Cheney 1970 paper).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — Cheney scavenge + V8/JVM/.NET cross-platform comparison