[TIL] V8 Heap 구조와 Garbage Collection

V8 Heap
├── New Space (Young Generation)
│   ├── Semi-space (from)
│   └── Semi-space (to)
├── Old Space (Old Generation)
├── Large Object Space
├── Code Space
└── Map Space

Semi-space 내부 할당:
 
  allocation_top (현재 위치)
        ↓
[obj1][obj2][obj3][        빈 공간        ]
                  ↑                       ↑
            allocation_top 이동     allocation_limit
 
새 객체 할당 = allocation_top을 객체 크기만큼 오른쪽으로 이동
→ malloc보다 훨씬 빠르다 (포인터 덧셈 한 번)
→ allocation_top이 allocation_limit에 도달하면 Scavenge 발동

// 이 객체는 New Space에 할당된다
// 내부적으로는 allocation_top 포인터가 객체 크기만큼 이동할 뿐
const temp = { x: 1, y: 2 };
 
// 함수가 끝나면 temp는 더 이상 참조되지 않으므로
// 다음 Scavenge에서 수거된다

// 모듈 스코프의 캐시 → Old Space로 승격될 가능성 높음
const cache = new Map();
 
export function getUser(id) {
  if (cache.has(id)) return cache.get(id);
  const user = db.fetchUser(id);
  cache.set(id, user);  // cache에 계속 쌓이면 Old Space가 커진다
  return user;
}

Old Space 할당 (free list 방식):
 
Sweep 후의 Old Space:
[live][  빈1  ][live][live][    빈2    ][live][  빈3  ]
       ↑                    ↑                  ↑
       free list로 연결: 빈1 → 빈2 → 빈3
 
새 객체 할당 요청 (크기: N bytes)
→ free list에서 N 이상인 빈 공간을 찾는다
→ 빈2에 할당하고, 남은 공간은 free list에 다시 등록
→ 적합한 공간을 못 찾으면 → Compact 또는 Heap 확장

// 큰 배열은 Large Object Space로 직접 간다
// V8 내부에서 kMaxRegularHeapObjectSize(약 128KB~256KB)를 초과하면
// Large Object Space에 할당된다
const hugeArray = new Array(1_000_000).fill(0);
 
// Buffer도 크기가 크면 Large Object Space 대상이다
// (단, Buffer의 실제 데이터는 V8 Heap 밖에 저장된다 — 다음 글에서 다룸)
const bigBuf = Buffer.alloc(1024 * 1024); // 1MB

// 같은 순서로 프로퍼티를 추가하면 → 같은 Hidden Class
const a = {};   // Hidden Class C0 (빈 객체)
a.x = 1;        // Hidden Class C0 → C1 (x를 가진 객체)
a.y = 2;        // Hidden Class C1 → C2 (x, y를 가진 객체)
 
const b = {};   // C0
b.x = 3;        // C0 → C1 (a와 같은 전이 경로!)
b.y = 4;        // C1 → C2 (a와 같은 Hidden Class 공유)
 
// 다른 순서로 추가하면 → 다른 Hidden Class
const c = {};   // C0
c.y = 5;        // C0 → C3 (y를 먼저 추가 → 다른 전이 경로)
c.x = 6;        // C3 → C4 (a, b와 다른 Hidden Class!)

app.get('/api/users/:id', async (req, res) => {
  const params = req.params;        // 요청마다 생성, 응답 후 죽음
  const query = buildQuery(params);  // 요청마다 생성, 응답 후 죽음
  const result = await db.run(query); // 요청마다 생성, 응답 후 죽음
  const json = JSON.stringify(result); // 요청마다 생성, 응답 후 죽음
  res.send(json);
  // → 이 함수 안의 모든 객체는 수명이 수십 ms
});

Scavenge 전:
┌─────────────────┐  ┌─────────────────┐
│   From-space    │  │   To-space      │
│ [A][B][C][D][E] │  │  (비어있음)       │
│  ↑       ↑      │  │                 │
│  live    live   │  │                 │
└─────────────────┘  └─────────────────┘
 
Scavenge 후:
┌─────────────────┐  ┌─────────────────┐
│   From-space    │  │   To-space      │
│  (비어있음)       │  │ [A][D]          │
│                 │  │  (살아남은 것만)   │
└─────────────────┘  └─────────────────┘
→ 역할 교대: To가 From이 되고, From이 To가 된다

function handleRequest() {
  const user = { name: "yeji" };  // ① New Space에 할당 (주소: 0x1000)
  const session = { user: user }; // ② New Space에 할당 (주소: 0x1020)
                                  //    session.user → 0x1000을 참조
  const temp = { ts: Date.now() }; // ③ New Space에 할당 (주소: 0x1040)
 
  // 함수 끝나기 전에 session을 반환한다고 가정
  return session;
  // temp는 이제 도달 불가능 (아무도 참조하지 않음)
}
const result = handleRequest();
// 이 시점에서 Scavenge가 발동하면...

Scavenge 과정 (참조 관계 복사):
 
From-space:
[user: 0x1000][session: 0x1020][temp: 0x1040]
                  ↓ 참조
              user(0x1000)
 
① 루트(result)에서 시작 → session(0x1020)에 도달
② session을 To-space로 복사 → 새 주소 0x2020
③ From-space 0x1020에 forwarding pointer 남김: "나 0x2020으로 이사했어"
④ session이 참조하는 user(0x1000)도 도달 가능 → To-space로 복사 → 0x2000
⑤ session.user 참조를 0x1000 → 0x2000으로 업데이트
⑥ temp(0x1040)는 아무도 참조하지 않음 → 복사하지 않음 → 자연스럽게 소멸
 
To-space:
[user: 0x2000][session: 0x2020]
                  ↓ 참조 (업데이트됨)
              user(0x2000)
 
→ From-space를 통째로 비움. temp가 차지하던 메모리는 별도 해제 없이 사라짐

첫 번째 Scavenge: From → To (살아남음, 플래그 설정)
두 번째 Scavenge: From → Old Space (승격!)

// 승격이 자주 일어나는 패턴을 --trace-gc로 관찰
const sessions = new Map();
 
app.get('/login', (req, res) => {
  const session = {                // ① New Space 할당
    userId: req.body.id,
    token: generateToken(),
    createdAt: Date.now(),
  };
  sessions.set(session.token, session); // ② Map에 저장 → 참조 유지
  res.json({ token: session.token });
  // session은 sessions Map이 참조하고 있으므로
  // Scavenge에서 죽지 않고 → Old Space로 승격
  // sessions.delete()를 안 하면 Old Space가 계속 커짐
});

3색 마킹의 의미:
 
흰색 (White) = 아직 방문하지 않음 (기본 상태, GC 후 수거 대상)
회색 (Grey)  = 자신은 발견했지만, 참조하는 자식들을 아직 다 처리하지 않음
검정 (Black) = 자신과 자식 모두 처리 완료 (살아있음 확정)

마킹 과정 (단계별):
 
[시작] 모든 객체는 흰색
       루트에서 직접 닿는 객체를 회색으로 표시
 
        global (BLACK)
        ├── cache (GREY) → 아직 자식 미처리
        └── config (GREY) → 아직 자식 미처리
 
[진행] 회색 객체를 하나 꺼내서, 자식들을 회색으로 표시하고, 자신은 검정으로
 
        global (BLACK)
        ├── cache (BLACK)
        │    ├── key1 → userObj (GREY)
        │    └── key2 → userObj (GREY)
        └── config (BLACK)
 
[완료] 회색 객체가 더 없으면 마킹 종료
       아직 흰색인 객체 = 도달 불가능 = 수거 대상

Sweep 과정:
 
마킹 후 Old Space 페이지:
[BLACK][WHITE][BLACK][WHITE][WHITE][BLACK]
   ↓      ↓     ↓      ↓      ↓     ↓
[유지 ][해제 ][유지 ][해제  ][해제 ][유지 ]
 
해제된 공간은 free list에 등록:
free list: [빈1] → [빈2+빈3 병합] → ...
→ 인접한 빈 공간은 가능하면 병합하여 더 큰 연속 공간을 만든다

Compact 전:
[live][    ][live][  ][live][      ][live]
         ↓ fragmentation이 심함
 
Compact 후:
[live][live][live][live][                ]
                        ↑ 큰 연속 공간 확보

기존:
메인 스레드:  [====== GC ======][-------- JS --------]
 
Parallel:
메인 스레드:  [== GC ==][-------- JS --------]
헬퍼 스레드1: [== GC ==]
헬퍼 스레드2: [== GC ==]
→ 같은 일을 여러 스레드가 나눠서 → STW 시간 단축

기존:
[=============== GC ===============][JS][JS][JS]
 
Incremental:
[GC][JS][GC][JS][GC][JS][GC][JS][GC][JS]
→ 한 번에 오래 멈추는 대신, 짧게 여러 번 멈춤

// incremental marking 도중의 위험한 상황
 
const parent = { child: null };  // parent는 이미 BLACK (처리 완료)
const orphan = { data: "중요" }; // orphan은 아직 WHITE (미발견)
 
// ⚠️ 마킹 중간에 JS가 실행되면서:
parent.child = orphan;
// parent(BLACK)가 orphan(WHITE)을 참조하게 됨
// 하지만 parent는 이미 처리 완료이므로 orphan을 방문하지 않음
// → orphan이 WHITE인 채로 남아서 잘못 수거될 수 있다!

Write Barrier (개념적 의사 코드):
 
parent.child = orphan 실행 시:
  ① 일반 쓰기: parent.child = orphan
  ② barrier 체크:
     if (marking_in_progress &&
         parent가 BLACK &&
         orphan이 WHITE) {
       orphan을 GREY로 변경     // "이 객체 아직 처리 안 했어!"
       worklist에 orphan 추가   // 나중에 다시 방문하도록
     }

메인 스레드:  [---------- JS 계속 실행 ----------][짧은 pause]
백그라운드:   [=== concurrent marking ===]
→ 마킹의 대부분이 백그라운드에서 발생
→ 메인 스레드는 마지막 finalize 단계에서만 잠깐 멈춤

기존 (64비트 포인터):
┌────────────────────────────────┐
│         0x7f3a2b4c5d6e7f80     │  ← 8 bytes per pointer
└────────────────────────────────┘
 
Pointer Compression:
┌────────┐ + base register
│ offset │ ← 4 bytes per pointer
└────────┘
실제 주소 = base + offset

// 이 객체의 각 프로퍼티가 포인터를 하나씩 가진다
const obj = {
  name: "yeji",   // 포인터 → 문자열 객체
  age: 25,         // Smi (Small Integer) - 포인터 아닌 즉시값
  skills: [],      // 포인터 → 배열 객체
};
// Pointer Compression으로 각 포인터가 8B → 4B로 줄어듦

# Old Space를 4GB로 확장
node --max-old-space-size=4096 server.js

# Semi-space를 64MB로 확장
node --max-semi-space-size=64 server.js

node --expose-gc -e "
  console.log(process.memoryUsage().heapUsed);
  global.gc();
  console.log(process.memoryUsage().heapUsed);
"

node --trace-gc server.js
# 출력 예시:
# [4312:0x...]  1234 ms: Scavenge 15.2 (20.4) -> 5.1 (20.4) MB, 1.2 / 0.0 ms
# [4312:0x...]  5678 ms: Mark-Compact 45.3 (60.2) -> 32.1 (55.0) MB, 12.5 / 0.0 ms

New Space의 allocation_top이 allocation_limit에 도달
→ "Semi-space가 꽉 찼다"
→ Scavenge 발동

① Old Space 크기가 임계값을 넘었을 때
   - V8은 이전 GC 후의 Heap 크기를 기반으로 다음 GC 임계값을 계산
   - growth factor: 이전 live 크기의 약 1.5~2배
 
② allocation failure
   - Old Space에서 free list로도 할당할 공간을 못 찾을 때
 
③ 외부 메모리 압박 (external memory pressure)
   - ArrayBuffer, Buffer 등 외부 메모리가 크게 늘어났을 때
   - V8이 "외부 메모리가 너무 크니 Heap 정리해라" 신호를 받음

// Major GC 트리거를 관찰하는 코드
const v8 = require('v8');
 
setInterval(() => {
  const heap = v8.getHeapStatistics();
  console.log({
    // 현재 사용 중인 Heap 크기
    used: `${(heap.used_heap_size / 1024 / 1024).toFixed(1)}MB`,
    // V8이 OS로부터 확보한 전체 Heap 크기
    total: `${(heap.total_heap_size / 1024 / 1024).toFixed(1)}MB`,
    // Heap 크기 상한 (이 값에 도달하면 OOM)
    limit: `${(heap.heap_size_limit / 1024 / 1024).toFixed(0)}MB`,
    // 외부 메모리 (ArrayBuffer 등, V8 Heap 밖)
    external: `${(heap.external_memory / 1024 / 1024).toFixed(1)}MB`,
  });
}, 5000);
 
// --trace-gc와 함께 실행하면 GC 타이밍과 Heap 상태를 동시에 볼 수 있다
// node --trace-gc app.js

// V8 소스 src/heap/heap.h (개념적 구조, 실제 코드는 더 복잡)
class Heap {
  // 각 Space가 멤버로 존재
  NewSpace* new_space_;           // Young Generation
  OldSpace* old_space_;           // Old Generation
  LargeObjectSpace* lo_space_;    // 큰 객체 전용
  CodeSpace* code_space_;         // JIT 코드
  MapSpace* map_space_;           // Hidden Class
 
  // GC 진입점
  // reason: "allocation failure", "external memory pressure" 등
  void CollectGarbage(GarbageCollectionReason reason);
 
  // Minor GC만 실행
  void CollectYoungGeneration();
 
  // Major GC 실행
  void CollectOldGeneration();
};

// 개념적 흐름 (실제 코드에서 추출한 구조)
void MarkCompactCollector::CollectGarbage() {
  // Phase 1: Mark - 도달 가능한 객체 표시
  MarkLiveObjects();      // tri-color marking으로 살아있는 객체 찾기
  // ↳ MarkRoots()        // 루트(전역, 스택)부터 시작
  // ↳ ProcessMarkingWorklist()  // worklist의 회색 객체 처리
 
  // Phase 2: Clear - WeakRef, FinalizationRegistry 정리
  ClearNonLiveReferences();
 
  // Phase 3: Sweep - 죽은 객체 해제
  Sweep();                // 흰색 객체의 메모리를 free list로 반환
 
  // Phase 4: Compact (필요시) - 단편화 해소
  if (ShouldCompact()) {
    Compact();            // 살아있는 객체를 이동하여 빈 공간 확보
  }
}

// Scavenger의 핵심 로직 (개념적)
void Scavenger::ScavengeObject(HeapObject object) {
  // 이미 복사된 객체면 forwarding pointer 따라감
  if (object.HasForwardingAddress()) {
    return object.GetForwardingAddress();
  }
 
  // 승격 조건 확인: 이미 한 번 살아남았거나 To-space가 거의 찼으면
  if (ShouldPromote(object)) {
    // Old Space로 승격
    HeapObject target = old_space_->AllocateRaw(object.Size());
    MigrateObject(target, object);  // 복사
    object.SetForwardingAddress(target);  // 원래 위치에 포워딩
    return target;
  }
 
  // To-space로 복사
  HeapObject target = to_space_->AllocateRaw(object.Size());
  MigrateObject(target, object);
  object.SetForwardingAddress(target);
  return target;
}

// gc-observe.js
// 실행: node --trace-gc --expose-gc gc-observe.js
 
const v8 = require('v8');
 
function printHeap(label) {
  const mem = process.memoryUsage();
  console.log(`\n[${label}]`);
  console.log(`  heapUsed:  ${(mem.heapUsed / 1024 / 1024).toFixed(1)}MB`);
  console.log(`  heapTotal: ${(mem.heapTotal / 1024 / 1024).toFixed(1)}MB`);
  console.log(`  rss:       ${(mem.rss / 1024 / 1024).toFixed(1)}MB`);
}
 
// 1. 초기 상태
global.gc();  // 깨끗한 상태에서 시작
printHeap('초기 상태');
 
// 2. 단기 객체 대량 생성 → Scavenge 관찰
console.log('\n--- 단기 객체 100만 개 생성 ---');
for (let i = 0; i < 1_000_000; i++) {
  const temp = { index: i, data: `item-${i}` };
  // temp는 루프 끝에서 참조를 잃음 → 다음 Scavenge에서 수거
  // --trace-gc 출력에서 "Scavenge" 로그가 여러 번 찍히는 것을 관찰
}
printHeap('단기 객체 생성 후');
 
// 3. 장기 객체 생성 → Old Space 성장 관찰
console.log('\n--- 장기 객체 10만 개를 Map에 저장 ---');
const longLived = new Map();
for (let i = 0; i < 100_000; i++) {
  longLived.set(i, { index: i, payload: 'x'.repeat(100) });
  // Map에 저장 → 참조 유지 → 승격 → Old Space에 쌓임
}
printHeap('장기 객체 저장 후');
 
// 4. GC 실행 후에도 Old Space는 줄지 않음 (참조가 살아있으므로)
global.gc();
printHeap('GC 후 (Map 참조 유지)');
 
// 5. 참조 해제 후 GC → Old Space 해제 관찰
longLived.clear();
global.gc();
printHeap('Map.clear() + GC 후');
// → heapUsed가 크게 줄어든 것을 확인할 수 있다
// → --trace-gc에서 Mark-Compact 로그와 함께 해제된 크기를 볼 수 있다

JS 객체 생성
    ↓
New Space (Young Gen) ←── Scavenge (Minor GC, 빠름)
    ↓ 생존
Old Space (Old Gen) ←── Mark-Sweep-Compact (Major GC, 느림)
    ↓ Orinoco로 최적화
Concurrent + Parallel + Incremental → STW 최소화