JVM GC 내부 구조: TLAB, 카드 테이블, 배리어까지

// 개념적 표현 (실제 JVM 내부는 C++ 구현)
Object allocate(int size) {
    if (tlab.remaining() >= size) {
        Object obj = tlab.bump(size);
        return obj;
    }
    return slowPathAllocate(size); // TLAB 부족 -> 전역 힙에서 재할당
}

Thread-1의 TLAB:
┌──────────────────────────────────────────┐
│ [obj1][obj2][obj3][  free space  ...   ] │
│                    ↑                     │
│                   top (bump pointer)     │
│                              ↑           │
│                             end          │
└──────────────────────────────────────────┘

할당: top += objectSize (원자적 연산 불필요)
TLAB 소진: JVM이 새 TLAB을 Eden에서 할당 (이때만 CAS 필요)

JVM은 스레드별 할당 속도에 따라 TLAB 크기를 동적으로 조정합니다.

할당이 빠른 스레드 → 큰 TLAB (waste 줄임)
할당이 느린 스레드 → 작은 TLAB (메모리 절약)

모니터링: -XX:+PrintTLAB (JDK 8) 또는 -Xlog:gc+tlab=debug (JDK 11+)

[Heap - Old Region]
| Card0 | Card1 | Card2 | Card3 | Card4 | Card5 | ... |
  clean   dirty   clean   dirty   clean   clean

Card Table (byte array):
[0x00] [0x01] [0x00] [0x01] [0x00] [0x00] ...

Minor GC → Card1(512B), Card3(512B)만 스캔 (Old 전체 수 GB 대신)

카드 크기: 512 bytes
카드 테이블 엔트리: 1 byte per card
오버헤드: 1/512 ≈ 0.2% (힙 크기 대비)

예) 4GB 힙 → 카드 테이블 약 8MB

문제: 같은 캐시 라인(64B)에 여러 카드 엔트리가 들어감
     → 여러 스레드가 인접 카드를 동시에 dirty 표시할 때 캐시 라인 경합

해결: JDK 7u4+에서 -XX:+UseCondCardMark 옵션
     → 이미 dirty인 카드는 다시 쓰지 않음 (조건부 기록)
     
if (cardTable[index] != DIRTY) {
    cardTable[index] = DIRTY;  // 이미 dirty면 skip → cache bounce 방지
}

flowchart LR
    R1[Region 1] -->|ref| R2[Region 2]
    R3[Region 3] -->|ref| R2
    R4[Region 4] -->|ref| R2
    R2 -->|RSet 기록| R1 & R3 & R4

1. Sparse: PRT(Per Region Table)에 카드 인덱스 직접 저장
   → 참조하는 Region이 적을 때 (공간 효율)

2. Fine-grained: 비트맵으로 카드 단위 추적
   → 참조하는 Region이 중간 수준일 때

3. Coarse-grained: Region 전체를 하나의 비트로 표시
   → 참조하는 Region이 너무 많을 때 (fallback)

문제: RSet은 힙의 5~20%를 소비할 수 있음 (특히 Region 간 참조가 많을 때)

모니터링:
  -Xlog:gc+remset=debug  (JDK 11+)
  
출력 예시:
  "Remembered Sets: ... total 45.2M, static 12.3M, occupied 32.9M"

튜닝:
  -XX:G1HeapRegionSize=8m  (Region 크기 키우기 → Region 수 줄임 → RSet 축소)
  단, Region이 너무 크면 Mixed GC 효율 저하

// Java 코드
parent.child = newChild;

// JVM이 실제로 실행하는 것 (의사코드)
void writeReference(Object parent, Object newChild) {
    parent.child = newChild;                    // 실제 할당
    
    // === Write Barrier 시작 ===
    if (isOldToYoung(parent, newChild)) {
        cardTable.markDirty(parent);            // Card Table 갱신
    }
    if (isG1()) {
        rememberedSet.update(parent, newChild); // RSet 갱신
        satbQueue.enqueue(oldChild);            // SATB 마킹 (동시 마킹 지원)
    }
    // === Write Barrier 끝 ===
}

문제: GC가 동시에 마킹하는 동안 애플리케이션이 참조를 변경하면?
     → 살아있는 객체를 "죽었다"고 잘못 판단할 수 있음 (floating garbage보다 심각)

해결: SATB Write Barrier
  1. 참조 변경 전에 기존 값(old reference)을 SATB 큐에 기록
  2. GC 마킹 단계에서 SATB 큐를 처리하여 누락 방지
  
트레이드오프: 마킹 시작 시점의 "스냅샷"을 기준으로 하므로,
             마킹 중에 죽은 객체가 이번 사이클에서 수집되지 않을 수 있음 (Floating Garbage)
             → 다음 사이클에서 수집됨

Write Barrier 대신 Read Barrier를 사용하는 이유:

G1: Write Barrier + STW Remark 단계 필요
ZGC: Read Barrier + Colored Pointer로 STW를 1ms 이하로

ZGC Read Barrier 의사코드:
Object read(Object* ref) {
    Object obj = *ref;
    if (needsRelocation(obj)) {
        obj = relocateAndRemap(obj);   // 객체가 이동했으면 새 주소로 포워딩
        *ref = obj;                     // 참조 자체를 업데이트 (self-healing)
    }
    return obj;
}

비용: 읽기마다 1~2 사이클 추가 (조건 분기)
이점: STW 없이 객체 이동/압축 가능

flowchart TD
    A[Young GC] -->|Eden 가득| B[Eden + Survivor 수집]
    B -->|Survivor 임계 초과| C[Old Region으로 승격]
    C -->|Old 비율 임계| D[Concurrent Marking]
    D -->|마킹 완료| E[Mixed GC]
    E -->|Old Region 선별 수집| F[필요시 Full GC]
    
    style A fill:#c8e6c9
    style D fill:#fff9c4
    style F fill:#ffcdd2

flowchart TD
    A[GC 선택] --> B{p99 지연 요구?}
    B -->|< 10ms| C{힙 크기?}
    C -->|< 64GB| D[Shenandoah]
    C -->|> 64GB| E[ZGC]
    B -->|10~200ms 허용| F{배치/처리량 중심?}
    F -->|Yes| G[Parallel GC]
    F -->|No| H[G1 GC]
    B -->|지연 무관, 처리량 극대화| G

# 운영 환경 권장 설정
java \
  -Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=50m \
  -Xlog:gc+heap=debug \
  -Xlog:gc+age=debug \
  -Xlog:safepoint=info \
  -jar app.jar

[2026-03-28T11:00:00.123+0900] GC(142) Pause Young (Normal) (G1 Evacuation Pause)
[2026-03-28T11:00:00.123+0900] GC(142)   Eden regions: 150->0(148)
[2026-03-28T11:00:00.123+0900] GC(142)   Survivor regions: 12->14(20)
[2026-03-28T11:00:00.123+0900] GC(142)   Old regions: 380->382
[2026-03-28T11:00:00.123+0900] GC(142)   Humongous regions: 4->4
[2026-03-28T11:00:00.123+0900] GC(142) Pause Young (Normal) 2150M->400M(4096M) 12.345ms

읽기:
- Eden 150개 Region → 0개 (전부 수집, 148개 새로 할당 예정)
- Survivor 12 → 14 (일부 승격 전 생존)
- Old 380 → 382 (2개 Region에 승격 발생)
- 총 힙: 2150MB → 400MB (1750MB 회수)
- STW: 12.345ms ✅ (양호)

1. GCViewer (오픈소스)
   - GC 로그 파일을 시각화
   - Pause time 분포, 힙 사용량 추이 확인
   
2. GCEasy (온라인)
   - https://gceasy.io
   - 로그 업로드 → 자동 분석 리포트
   - 메모리 누수 탐지, 튜닝 제안

3. JFR (Java Flight Recorder)
   - JDK 내장, 프로덕션 오버헤드 < 1%
   - GC 이벤트 + 할당 프로파일링 통합

# JFR 시작
jcmd <pid> JFR.start duration=60s filename=gc-analysis.jfr

# JFR 분석 (JDK Mission Control)
jmc gc-analysis.jfr

# G1 기반 저지연 튜닝
java \
  -Xms4g -Xmx4g \
  -XX:+UseG1GC \
  -XX:MaxGCPauseMillis=50 \
  -XX:G1HeapRegionSize=4m \
  -XX:InitiatingHeapOccupancyPercent=35 \
  -XX:G1ReservePercent=15 \
  -XX:+ParallelRefProcEnabled \
  -jar api-server.jar

# 해설:
# MaxGCPauseMillis=50  → GC에게 "50ms 이내로 끝내라" 목표 제시
# IHOP=35              → Old 35%부터 동시 마킹 시작 (Full GC 예방)
# G1ReservePercent=15  → To-space exhausted 방지용 예비 공간

# Parallel GC 처리량 튜닝
java \
  -Xms8g -Xmx8g \
  -XX:+UseParallelGC \
  -XX:ParallelGCThreads=8 \
  -XX:MaxGCPauseMillis=500 \
  -XX:GCTimeRatio=19 \
  -jar batch-worker.jar

# 해설:
# ParallelGC           → 처리량 우선 (STW 길어도 OK)
# GCTimeRatio=19       → GC 시간 비율 5% 이하 목표 (1/(1+19))
# Pause 500ms          → 배치에선 충분히 허용 가능

# ZGC (JDK 17+)
java \
  -Xms32g -Xmx32g \
  -XX:+UseZGC \
  -XX:+ZGenerational \
  -XX:SoftMaxHeapSize=28g \
  -jar realtime-service.jar

# 해설:
# ZGenerational        → JDK 21+ 세대별 ZGC (처리량 30% 향상)
# SoftMaxHeapSize      → 이 값 초과 시 더 적극적으로 GC (OOM 방지)
# STW: 항상 < 1ms      → 32GB 힙에서도 보장

시간 →
힙 사용량:
  ╱╲    ╱╲    ╱╲    ╱╲        ← 정상: GC 후 기준선 일정
 ╱  ╲  ╱  ╲  ╱  ╲  ╱  ╲
╱    ╲╱    ╲╱    ╲╱    ╲──

  ╱╲   ╱╲   ╱╲   ╱╲   ╱╲    ← 누수: GC 후 기준선이 점진적으로 상승
 ╱  ╲ ╱  ╲ ╱  ╲ ╱  ╲ ╱  ╲
╱    ╲   ╲   ╲   ╲   ╲
     ↗ 기준선 상승 ↗

1. GC 로그에서 Full GC 후 힙 사용량 추세 확인
   → 기준선이 계속 올라가면 누수 의심

2. 힙 덤프 확보
   jmap -dump:live,format=b,file=heap.hprof <pid>
   또는 -XX:+HeapDumpOnOutOfMemoryError (사전 설정)

3. MAT(Memory Analyzer Tool)로 분석
   → Dominator Tree에서 큰 객체 확인
   → Leak Suspects 리포트 확인

4. 일반적 원인:
   - static Map/List에 무한 누적
   - 이벤트 리스너 해제 안 함
   - ThreadLocal 정리 안 함 (스레드 풀 환경)
   - ClassLoader 누수 (동적 클래스 로딩)