2nd/10_Wiki/Topics/Domain_Programming/Architecture/Incremental_Marking.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-incremental-marking	Incremental Marking	10_Wiki/Topics	verified	self	Incremental GC Tri-color Marking	none	A	0.9	applied	architecture gc runtime performance memory		2026-05-10	pending	language framework cpp v8-go-jvm

Incremental Marking

매 한 줄

"매 GC mark phase 의 small slice 의 mutator 의 interleave 의 통한 pause time 의 reduction". 매 Dijkstra 의 1978 tri-color abstraction 의 origin, 매 V8 (2011), Go (2015 concurrent), ZGC/Shenandoah (sub-millisecond) 의 modern 의 ubiquity — 매 stop-the-world 의 long pause 의 avoid.

매 핵심

매 Tri-Color Abstraction

• White: 매 unvisited / unreachable candidate.
• Gray: 매 visited 의 children 의 X.
• Black: 매 fully scanned (children 의 gray/black).
• Invariant: 매 black → white edge 의 X (strong invariant) 의 violation 의 fix → write barrier.

매 Write Barrier 종류

• Dijkstra (insertion): black → white 의 store 의 시 white 의 gray 로 promote.
• Yuasa (deletion / SATB): gray pointer 의 overwrite 시 old target 의 gray 로 (snapshot-at-the-beginning).
• Hybrid: Go 1.8+ 의 hybrid barrier (stack 의 black 의 가정).

매 응용

1. V8 (Chrome/Node) — incremental + concurrent + lazy sweep.
2. Go — concurrent tri-color mark, sub-ms STW.
3. JVM ZGC / Shenandoah — colored pointers / load barriers.

💻 패턴

Dijkstra Write Barrier (Pseudo-C)

void write_barrier(Object** slot, Object* new_val) {
  if (gc_phase == MARKING && new_val != NULL && new_val->color == WHITE) {
    new_val->color = GRAY;
    mark_stack_push(new_val);
  }
  *slot = new_val;
}

Tri-Color Marking Loop

void incremental_mark_step(size_t budget_bytes) {
  size_t scanned = 0;
  while (scanned < budget_bytes && !mark_stack.empty()) {
    Object* obj = mark_stack.pop();   // gray
    for (Object* child : obj->refs()) {
      if (child->color == WHITE) {
        child->color = GRAY;
        mark_stack.push(child);
      }
    }
    obj->color = BLACK;
    scanned += obj->size();
  }
}

V8-Style Step Scheduling

// Allocation 의 통한 mark step 의 trigger
void* allocate(size_t n) {
  void* p = bump_alloc(n);
  marking_progress_ += n;
  if (marking_progress_ >= step_threshold_) {
    incremental_mark_step(/*budget=*/n * 2);  // pay-as-you-go
    marking_progress_ = 0;
  }
  return p;
}

Go-Style SATB-ish Hybrid Barrier

// runtime/mbarrier.go (simplified)
//go:nowritebarrierrec
func gcWriteBarrier(slot *unsafe.Pointer, ptr unsafe.Pointer) {
    if writeBarrier.enabled {
        // Shade ptr (Dijkstra) AND shade *slot (Yuasa)
        shade(ptr)
        shade(*slot)
    }
    *slot = ptr
}

Concurrent Mark Termination

void mark_termination() {
  stop_the_world();              // brief STW
  drain_remaining_mark_stack();  // flush per-thread buffers
  weak_ref_processing();
  start_concurrent_sweep();
  resume_world();
}

매 결정 기준

상황	Approach
Latency-critical (game, trading)	ZGC / Shenandoah (sub-ms)
Throughput-critical (batch)	Parallel STW collector
Mid-size heap, mixed	G1, V8 incremental
Tiny heap (embedded)	Reference counting / simple mark-sweep

기본값: 매 modern runtime 의 기본 (V8, Go, JVM G1) — explicit tuning 없이 incremental marking 의 enabled.

🔗 Graph

• 부모: Garbage Collection · Memory Management
• 변형: Concurrent-Marking
• 응용: V8
• Adjacent: Write Barrier · Reference-Counting

🤖 LLM 활용

언제: GC pause 의 root cause 의 analysis, write barrier 의 correctness 의 reasoning, GC log 의 parse. 언제 X: production GC tuning 의 final decision (workload-specific benchmark 필수).

❌ 안티패턴

• Missing write barrier: black → white 의 invariant 의 violation 의 → premature reclamation 의 use-after-free.
• Unbounded step: incremental step 의 budget 의 X → STW-equivalent pause.
• Floating garbage 의 ignore: SATB 의 dead 가 mark, 매 cycle 의 retain — frequent collection 의 통한 mitigation.
• Allocator 의 black allocation 의 fail: marking 중 allocate 의 white → 매 next cycle 까지 reachable 의 보장 의 X.

🧪 검증 / 중복

• Verified (Dijkstra "On-the-fly Garbage Collection" 1978, V8 blog, Go GC design doc, Hudson "A Unified Theory of GC").
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — incremental GC marking 의 full content