2nd/10_Wiki/Topics/Architecture/Generational_Hypothesis.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-generational-hypothesis	Generational Hypothesis	10_Wiki/Topics	verified	self	Weak Generational Hypothesis 세대 가설	none	A	0.9	applied	gc runtime memory		2026-05-10	pending	language framework java jvm

Generational Hypothesis

매 한 줄

"매 most objects die young — 매 long-lived objects rarely reference young ones". 매 1984 Lieberman & Hewitt 의 observation 이 modern GC (G1, ZGC, Shenandoah, .NET, V8) 의 generational layout 의 foundation 으로 굳어졌다. 매 2026 시점, ZGC sub-millisecond pause 도 매 weak hypothesis 의 가정 위에서 동작한다.

매 핵심

매 두 hypothesis

• Weak: 매 newly allocated objects 의 majority 가 young 일 때 die.
• Strong: 매 old objects 의 references 의 대부분이 매 다른 old objects 를 가리킨다 (cross-gen 은 rare).

매 generational GC 의 design

• Young / Old generation 으로 heap 의 split.
• Young 은 매 frequent + cheap (copying / scavenge).
• Old 은 매 infrequent + expensive (mark-compact, concurrent).
• Write barrier 로 old→young reference 의 track (card table / remembered set).

매 응용

1. HotSpot G1 / ZGC — region-based, 여전히 generational (ZGC 는 2024 generational 추가).
2. V8 (Chrome / Node) — Scavenger (young) + Mark-Compact (old).
3. .NET CLR — Gen 0 / 1 / 2 + LOH.
4. Go — non-generational concurrent mark-sweep (의도적 trade-off).

💻 패턴

Young allocation (Java HotSpot)

// Eden 에 allocate — TLAB (Thread-Local Allocation Buffer) 의 bump pointer
public List<String> formatNames(List<User> users) {
    List<String> out = new ArrayList<>(users.size()); // Eden
    for (User u : users) {
        out.add(u.firstName() + " " + u.lastName());  // 매 short-lived String 들
    }
    return out; // caller 가 hold 하지 않으면 매 next minor GC 에서 collect
}

Card table write barrier (개념)

// old→young store 시 매 card 를 dirty mark
void oop_store(oop* field, oop value) {
    *field = value;
    if (in_old_gen(field) && in_young_gen(value)) {
        card_table[((uintptr_t)field) >> 9] = DIRTY;
    }
}
// minor GC 시 dirty card 만 scan → 매 old gen 전체 scan 회피

Tenuring threshold tuning

# HotSpot — survivor 에서 N 번 살아남으면 promote
java -XX:MaxTenuringThreshold=8 \
     -XX:+PrintTenuringDistribution \
     -Xlog:gc*=info \
     -jar app.jar

ZGC generational (Java 21+)

java -XX:+UseZGC -XX:+ZGenerational -Xmx16g -jar app.jar
# 매 sub-ms pause + generational 의 throughput 회복

.NET allocation pinning

// LOH (Large Object Heap) → 85_000 bytes 이상 즉시 Gen 2 로
// 매 short-lived large array 는 ArrayPool 로 회피
var buf = ArrayPool<byte>.Shared.Rent(1 << 20);
try { Process(buf); } finally { ArrayPool<byte>.Shared.Return(buf); }

V8 generational (Node.js)

// 매 short-lived object → new space (Scavenge, ~수 ms)
function handle(req) {
  const tmp = { id: req.id, ts: Date.now() }; // new space
  return JSON.stringify(tmp);                  // 매 die young
}

Allocation profiling

# async-profiler — 매 young allocation hotspot 찾기
./profiler.sh -e alloc -d 30 -f alloc.html <pid>

매 결정 기준

상황	Approach
Throughput 우선 batch	Parallel GC (generational copying)
Low-latency service	ZGC generational / Shenandoah
Predictable small heap	G1 (default Java 17+)
Allocation-heavy hot loop	object reuse / pooling 으로 promotion 회피
Large long-lived cache	off-heap (Chronicle, MapDB) 로 old gen pressure 제거

기본값: Java 21+ 의 G1 (default), latency critical 은 ZGC generational.

🔗 Graph

• 부모: Garbage Collection · Memory Management
• Adjacent: Write Barrier

🤖 LLM 활용

언제: GC pause 진단 / heap sizing / young vs old gen tuning 의 reasoning. 언제 X: 매 non-GC language (Rust, C++) — 매 ownership / RAII 가 대신.

❌ 안티패턴

• Premature tenuring: 매 young size 너무 작아 매 short-lived object 가 old 로 promote → full GC 폭증.
• Finalizer abuse: 매 finalizable object 는 매 한 cycle 더 살아남아 weak hypothesis 위반.
• Huge static caches: old gen 을 채워 매 mark phase 의 cost 증가.
• GC tuning before profiling: 매 actual allocation profile 없이 flag 만 추가.

🧪 검증 / 중복

• Verified (Lieberman & Hewitt 1983, Ungar 1984, Jones & Lins Garbage Collection 1996, Oracle HotSpot docs, OpenJDK ZGC JEP 439).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — generational hypothesis + modern GC (ZGC, V8, .NET) 정리