2nd/10_Wiki/Topic_Programming/DevOps_and_Security/Stop-the-world.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-stop-the-world	Stop the world	10_Wiki/Topics	verified	self	P-Reinforce-AUTO-D2D9B2 STW GC pause Stop-the-world	none	A	0.95	applied	gc runtime performance latency jvm v8		2026-05-10	pending	language framework Java / JS / Go HotSpot / V8 / Go runtime

Stop the world

매 한 줄

"매 GC + 매 mutator 의 동시 실행 매 X — 매 모든 application thread 의 freeze, 매 GC 의 reclaim 의 후 의 resume". 1960s LISP MTS GC 매 origin → 1990s incremental → 2010s concurrent → 2026 매 ZGC / Shenandoah / Go 1.5+ 의 sub-millisecond STW. 매 STW 매 매 latency 의 archenemy.

매 핵심

매 왜 STW 의 필요

• Heap traversal consistency: 매 mark phase 매 reference graph 의 stable 의 require — 매 mutator 매 concurrent write 의 invariant break.
• Root scanning: 매 thread stack + 매 register 의 snapshot 의 atomic 매 collect.
• Pointer update: 매 compacting GC 매 매 reference 의 rewrite 의 atomic 매 require.

매 STW phase

• Initial mark (root scan) — 매 short.
• Final mark / remark — 매 mutator 의 missed reference 의 catch-up.
• Reference processing (weak/soft refs).
• Cleanup / class unloading.

매 modern GC 의 STW

• HotSpot G1: ~10-200ms (heap size 의 dependent).
• HotSpot ZGC (JDK 21+): < 1ms 매 always (concurrent compaction).
• HotSpot Shenandoah: < 10ms (Brooks pointers).
• Go runtime: < 0.5ms (concurrent + tri-color + write barrier).
• V8 Orinoco: < 1ms typical (parallel + concurrent + incremental).

매 응용

1. SLO design (p99 latency budget).
2. JVM tuning (heap + GC choice).
3. Real-time / financial / game 의 latency-critical app.

💻 패턴

Pattern 1: 매 JVM 의 STW 의 measure (GC log)

# Java 21+
java -Xlog:gc*:file=gc.log:time,uptime,level,tags -Xmx4g -XX:+UseZGC App
# 매 log 의 분석
grep 'Pause' gc.log | awk '{print $NF}' | sort -n | tail

Pattern 2: 매 V8 의 GC pause 의 trace (Node.js)

node --trace-gc --trace-gc-verbose app.js
# [12345:0x..] 1234 ms: Mark-sweep 64.5 (98.4) -> 32.1 (98.4) MB, 12.3 / 0.0 ms

Pattern 3: 매 Go 의 GODEBUG 의 STW trace

GODEBUG=gctrace=1 ./myapp
# gc 1 @0.012s 0%: 0.012+0.36+0.005 ms clock, ...
#               ^^^^^   ^^^^^^^^   ^^^^^
#              STW init   concurrent  STW final

Pattern 4: 매 STW-aware code (allocation 의 reduce)

// V8 매 large allocation 매 LO space → mark-sweep 의 trigger
// Hot path 매 매 allocation 의 minimize
const buf = Buffer.allocUnsafe(1024); // reuse
function process(data: Uint8Array): number {
  let sum = 0;
  for (let i = 0; i < data.length; i++) sum += data[i];  // 매 no allocation
  return sum;
}

Pattern 5: 매 production GC tuning (JVM)

# 매 SLO p99 < 50ms 매 latency-critical service
java -Xmx8g -Xms8g \
  -XX:+UseZGC -XX:+ZGenerational \
  -XX:+UnlockExperimentalVMOptions \
  -XX:SoftMaxHeapSize=6g \
  -Xlog:gc*:file=gc.log \
  -jar app.jar

매 결정 기준

상황	Approach
Java batch / throughput	Parallel GC (longer STW OK)
Java latency-critical (p99 < 50ms)	ZGC (JDK 21+) or Shenandoah
Java legacy heap < 4G	G1 (default JDK 17+)
Go service	runtime default — tune GOGC
Node.js 매 long-lived process	--max-old-space-size, profile incremental marking
매 Hard real-time (audio, robotics)	manual memory mgmt — 매 GC 의 X (Rust, C++)

기본값: 매 latency app — 매 ZGC (Java) / 매 default Go runtime / 매 V8 incremental.

🔗 Graph

• 부모: V8 가비지 컬렉션(Garbage Collection) · 가비지 컬렉터(Garbage Collector)
• 변형: Mark-Sweep-Compact(메이저 GC) · Major GC · Scavenge
• 응용: V8 Engine · 자바 가상 머신(JVM) · 동시성 및 점진적 마킹(Concurrent Incremental Marking)
• Adjacent: Memory Management · 오리노코(Orinoco GC) · Cheneys Algorithm

🤖 LLM 활용

언제: 매 GC log 의 parse + summarize, 매 STW outlier 의 root-cause hypothesis, 매 GC flag 의 trade-off 분석. 언제 X: 매 production GC flag 의 LLM-only 의 decision — 매 load test 의 confirm 의 필요.

❌ 안티패턴

• 매 GC 의 manual trigger (System.gc(), --expose-gc) 매 production — 매 STW 의 force, 매 worse latency.
• 매 huge heap (-Xmx32g) + 매 G1 의 expectation 의 STW < 10ms — 매 G1 의 multi-GB heap 매 longer pause 의 inevitable, 매 ZGC 의 use.
• 매 short-lived object 의 fixed pool 의 cache — 매 generational GC 의 already 의 efficient. 매 over-engineering.
• 매 GC log 의 production 의 disable — 매 incident 의 post-mortem 의 impossible.

🧪 검증 / 중복

• Verified (HotSpot ZGC tuning guide JDK 21, Go runtime/mgc.go, V8 blog 'Orinoco' 2020-2024).
• 신뢰도 A.
• 중복 risk: Major GC (related phase), 동시성 및 점진적 마킹(Concurrent Incremental Marking) (technique that 매 reduces STW).

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — STW phases, modern GC pause budgets, tuning patterns 정리