2nd/10_Wiki/Topic_Programming/DevOps_and_Security/Major GC.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-major-gc	Major GC	10_Wiki/Topics	verified	self	full-gc old-generation-gc mark-sweep-compact	none	A	0.9	applied	gc v8 memory performance jvm		2026-05-10	pending	language framework JavaScript V8

Major GC

매 한 줄

"매 Old generation 매 전체를 매 sweep 하는 매 비싼 GC cycle — 매 mark-sweep-compact 의 합성". 매 minor GC (Scavenge)와 대비되는 V8 의 second-tier collector — 매 long-lived object 의 final destination — 매 stop-the-world pause 의 가장 큰 원인.

매 핵심

매 단계

1. Mark: 매 root → reachable object tree-walk, mark bit set.
2. Sweep: 매 unmarked region 의 free list 추가.
3. Compact: 매 fragmentation 의 reduce 매 live object 매 좌측 이동.

매 trigger

• 매 old-space 매 limit 도달.
• 매 minor GC 매 promotion 매 spike.
• 매 manual --expose-gc + gc() 호출.

매 응용

1. 매 long-running Node.js server 매 latency 의 source.
2. 매 GC tuning 의 핵심 metric.

💻 패턴

매 GC log enable

node --trace-gc app.js
# 매 sample
# [12345:0x...] [Mark-Compact 250.4MB->180.2MB (300.0MB) 45.3 ms]

매 PerformanceObserver

const obs = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.detail.kind === 4) // 매 major GC
      console.log('Major GC:', entry.duration, 'ms');
  }
});
obs.observe({ entryTypes: ['gc'] });

매 heap snapshot

const v8 = require('v8');
v8.writeHeapSnapshot('/tmp/snap.heapsnapshot');
// 매 Chrome DevTools → Memory tab 매 load

매 incremental marking

node --trace-incremental-marking app.js
# 매 V8 매 mark phase 의 매 frame budget chunk 로 분할

매 max-old-space-size

node --max-old-space-size=4096 app.js  # 매 4GB
# 매 default 1.4GB on 64-bit

매 weak ref pattern

const cache = new Map();
const ref = new WeakRef(obj);
// 매 GC 매 obj 의 collect 매 cache 의 자동 cleanup
const finalizer = new FinalizationRegistry((key) => cache.delete(key));

매 promotion threshold tune

node --min-semi-space-size=64 --max-semi-space-size=128 app.js
// 매 young gen 의 크기 의 키워서 promotion 의 줄임

매 chrome devtools profile

// 매 Performance tab → Record → 매 GC marker 의 yellow bar
// 매 매 marker 매 click → reason: "allocation failure" / "external memory"

매 결정 기준

상황	Approach
매 frequent major GC	매 heap profile + leak hunt
매 GC pause >100ms	--max-old-space-size 의 increase
매 promotion 폭발	--max-semi-space-size 의 increase
매 long-lived cache	WeakRef + FinalizationRegistry

기본값: 매 trace-gc 로그로 baseline → 매 profile 후 매 tune.

🔗 Graph

• 부모: V8 가비지 컬렉션(Garbage Collection) · 가비지 컬렉터(Garbage Collector)
• 변형: Mark-Sweep-Compact(메이저 GC) · 오리노코(Orinoco GC)
• 응용: Stop-the-world · Memory Management
• Adjacent: Scavenge · New Space(Young Generation)

🤖 LLM 활용

언제: 매 Node.js latency spike 매 trace-gc 결과 의 해석. 언제 X: 매 minor GC 의 frequent — Scavenge 분석.

❌ 안티패턴

• manual gc() 의 spam: 매 incremental marking 의 방해.
• --expose-gc 의 prod: 매 attacker 의 DoS vector.
• heap-size 의 무한 증가: 매 swap 의 trash 매 latency 폭발.

🧪 검증 / 중복

• Verified (V8 12.x, Node.js 22+, 2026).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — Major GC mark-sweep-compact 단계 + tuning 정리