TIL

Chapter 6. 가비지 수집 기초

• 자바 가비지 수집의 요체는 시스템에 있는 모든 객체 수명을 정확히 몰라도 런타임이 대신 객체를 추적하여 객체를 알아서 제거하는 것
• 모든 가비지 수집 구현체는 다음 두 가지 원칙을 준수해야 한다.
  • 알고리즘은 반드시 모든 가비지를 수집해야 한다.
  • 살아 있는 객체는 절대로 수집해선 안 된다.
• 프로그래머가 저수준 세부를 신경쓰지 않는 대가로 저수준 제어권을 포기한다는 사상이 자바 관리 방식의 핵심

6.1 마크 앤 스위프

기본 개념을 쉽게 설명하고자 알고리즘을 단순화 했다. 실제 운영 JVM에서 GC가 수행되는 방법은 다르다.

• 초보적인 마크 앤 스위프 알고리즘은 할당됐지만, 아직 회수되지 않은 객체를 가리키는 포인터를 포함한 할당 리스트를 사용한다.

1. 할당 리스트를 순회하며 마크 비트를 지운다.
2. GC 루트부터 살아 있는 객체를 찾는다.
3. 찾은 객체마다 마크 비트를 세팅한다.
4. 할당 리스트를 순회하면서 마크 비트가 세팅되지 않은 객체를 찾는다.
   1. 힙에서 메모리를 회수해 프리 리스트에 되돌린다.
   2. 할당 리스트에서 객체를 삭제한다.
      • 살아 있는 객체는 대부분 DFS 방식으로 찾는다. - 이렇게 생성된 객체 그래프를 라이프 객체 그래프(live object graph)라 한다. - 접근 가능한 객체의 전이 패쇄(transitive closure of rechable objects)라고도 한다.

6.1.1 가비지 수집 용어

• STW (Stop The World)
  • GC 사이클이 발생하면 모든 애플리케이션 스레드가 중단된다.
  • 따라서 애플리케이션 코드는 GC 스레드가 바라보는 힙 상태를 무효화할 수 없다.
• 동시
  • GC 스레드는 애플리케이션 스레드와 동시 (병행) 실행될 수 있다.
  • 아주 어렵고 비싼 작업이고 실상 100% 동시 실행을 보장하진 않는다.
  • 핫스팟의 CMS(Concurrent Mark and Sweep)는 사실상 ‘준 동시’ 수집기
• 병렬
  • 여러 스레드를 동원해서 가비지 수집을 한다.
• 정확
  • 정확한 GC 스킴은 전체 가비지를 한방에 수집할 수 있게 힙 상태에 관한 충분한 타입 정보를 지니고 있다.
• 보수
  • 보수적인 스킴은 정확한 스킴의 정보가 없다. (타입 체계 무시)
  • 리소스를 낭비하는 일이 잦고 훨씬 비효율적
• 이동
  • 이동 수집기에서 객체는 메모리 여기저기를 오갈 수 있다.
  • 즉 객체 주소가 고정되지 않는다.
• 압착
  • 살아남은 객체는 GC 사이클 마지막에 연속된 단일 영역으로 배열된다.
  • 압착 수집기는 메모리 단편화를 방지한다.
• 방출
  • 수집 사이클 마지막에 할당된 영역을 완전히 비우고 살아남은 객체는 모두 다른 메모리 영역으로 방출된다.

6.2 핫스팟 런타임 개요

• 가비지 수집 작동 원리를 이해하려면 핫스팟 내부도 어느 정도 알아야 한다.
• 자바에서는 기본형(int 등)과 객체 레퍼런스의 두 값만 사용한다.
• 자바는 오직 오프셋 연산자(.)만으로 필드에 엑세스하거나 객체 레퍼런스의 메서드를 호출한다.
  • C와 달리 역참조 메커니즘이 없다.
  • 자바는 call-by-value 방식으로 메서드를 호출하는데 객체 레퍼런스의 경우 복사된 값은 객체의 주소다.

6.2.1 객체를 런타임에 표현하는 방법

• 핫스팟은 런타임에 oop라는 구조체로 자바 객체를 나타낸다.
  • oop(Ordinary Object Pointer)는 순수 포인터로 참조형 지역 변수 안에 위치하며 자바 메서드의 스택 프레임으로부터 자바 힙 메모리 내부를 가리킨다.
• oop 자료구조 중 instanceOop는 자바 클래스의 인스턴스를 나타낸다.
  • instanceOop의 메모리 레이아웃은 모든 객체에 대해 기계어 워드 2개로 구성된 헤더로 시작한다.
  • Mark 워드 - 인스턴스 관련 메타데이터를 가리키는 포인터
  • Klass 워드 - 클래스 메타데이터를 가리키는 포인터
• 자바 8부터 Klass가 자바 힙의 주 영역 밖으로 빠지게 되어 Klass 워드가 자바 힙 밖을 가리키게 되어 객체 헤더가 필요 없어졌다.
  • 자바 7까지는 Klass 워드가 힙의 일부인 펌젠 메모리 영역을 가리켰다.
  • 자바 힙에 있는 건 예외 없이 객체 헤더를 가져야 했다.
  • 실제로 옛 버전은 메타데이터를 klassOop로 참조했다.
• oop는 대부분 기계어 워드라 프로세서에 따라 32 또는 64비트이다.
  • 이러한 구조에서 메모리 낭비를 막기 위해 압축 oop 기법을 제공한다.
  • 힙에 있는 모든 객체의 Klass 워드, 참조형 인스턴스 필드, 객체 배열의 각원소가 압축된다.
• 핫스팟 객체 헤더 구성
  • Mark 워드 (32bit 환경 → 4byte, 64bit 환경 → 8byte)
  • Klass 워드 (압축됐을 수도 있음)
  • 객체가 배열이면 length 워드 (항상 32bit)
  • 32 비트 여백 (정렬 규칙 때문에 필요할 경우)
• JVM에서 자바 레퍼런스는 instanceOop를 제외한 어떤 것도 가리킬 수 없다.
  • 자바 값은 기본형 값 또는 instanceOop 주소에 대응되는 비트 패턴
  • 모든 자바 레퍼런스는 자바 힙의 주 영역의 주소를 가리키는 포인터
  • 자바 레퍼런스가 가리키는 주소에는 Mark 워드 + Klass 워드가 들어있다.
  • klassOop와 Class<?> 인스턴스는 다르며 klassOop를 자바 변수 안에 넣을 수 없다.

6.2.2 GC 루트 및 아레나

• GC 루트: 메모리의 ‘고정점(앵커 포인트)’으로 메모리 풀 외부에서 내부를 가리키는 포인터
  • 같은 메모리 풀 내부의 다른 메모리 위치를 가리키는 내부 포인터와 정반대인 외부 포인터이다.
• GC 루트 종류
  • 스택 프레임
  • JNI
  • 레지스터
  • (JVM 코드 캐시에서) 코드 루트
  • 전역 객체
  • 로드된 클래스의 메타데이터
  • ex) 힙의 객체를 가리키는 참조형 지역 변수
• 핫스팟 GC는 아레나 메모리 영역에서 작동한다.
• 핫스팟은 자바 힙을 관리할 때 시스템 콜을 하지 않는다.
  • 유저 공간에서 힙 크기를 관리

6.3 할당과 수명

• 가비지 수집이 일어나는 주된 원인은 다음 두 가지다.
  • 할당률
  • 객체 수명
• 할당률은 생성된 객체가 일정 기간 동안 사용한 메모리량이다.
  • 비교적 쉽게 측정할 수 있다.
• 객체 수명은 대부분 측정하기 어렵고 파악하기 복잡하여 할당률보다 더 핵심적인 요인이다.
• 가비지 수집에선 객체가 생성된 후 잠시 존재하고 그 상태를 보관하는 데 사용한 메모리를 다시 회수한다는 발상이 핵심

6.3.1 약한 세대별 가설

• 약한 세대별 가설(Week Generational Hypothesis)은 관찰을 통해 알게된 경험 지식으로 JVM 메모리 관리의 이론적 근간을 형성한다.

JVM 및 유사 소프트웨어 시스템에서 객체 수명은 이원적 분포 양상을 보인다. 거의 대부분의 객체는 아주 짧은 시간만 살아 있지만, 나머지 객체는 기대 수명이 훨씬 길다.

• 결론적으로 가비지 수집은
  • 단명 객체를 쉽고 빠르게 수집할 수 있어야 한다.
  • 장수 객체와 단명 객체를 완전히 떼어놓아야 한다.
• 핫스팟 가비지 수집 메커니즘
  • 객체마다 ‘세대 카운트’를 센다. (객체가 지금까지 무사 통과한 GC 횟수)
  • 큰 객체를 제외한 나머지 객체는 에덴 공간에 생성하고 살아남은 객체는 다른 곳으로 옮긴다.
  • 장수했다고 판단되는 객체는 별도의 메모리 영역(올드 또는 테뉴어드)에 보관한다.

• 중요한 것은 young 세대 내부를 가리키는 포인터를 계속 추적하는 기법이고 덕분에 GC에서 모든 메모리를 뒤질 필요가 없다.
• 늙은 객체가 젊은 객체를 참조할 일은 거의 없다.
  • 핫스팟은 카드 테이블이라는 자료 구조에 늙은 객체가 젊은 객체를 참조하는 정보를 기록한다.

6.4 핫스팟의 가비지 수집

• JVM은 메모리를 할당하고 유저 공간에서 연속된 단일 메모리 풀을 관리한다.
• 객체는 보통 에덴 영역에 생성되고 객체가 차지한 주소는 아주 빈번하게 바뀐다.
  • 객체를 이동시키는 것을 ‘방출’이라 하고 핫스팟 수집기는 대부분 방출 수집기이다.

6.4.1 스레드 로컬 할당

• JVM은 스레드 로컬 할당 버퍼(Thread-Local Allocation Buffer, TLAB)를 사용한다.
  • 에덴을 여러 버퍼로 나누어 각 스레드가 새 객체를 할당하는 구역으로 활용하는 구역
  • 각 스레드는 다른 스레드가 자신의 버퍼에 객체를 할당할 걱정을 하지 않아도 된다.
  • 핫스팟은 스레드에 발급한 TLAB 크기를 동적으로 조절한다.
• 애플리케이션 스레드가 TLAB를 다 채우면 JVM은 새 에덴 영역을 가리키는 포인터를 내어준다.

6.4.2 반구형 수집

• 반구형 (방출) 수집기는 (보통 크기가 같은) 두 공간을 사용하는 독특한 방출 수집기이다.
  • 단명 객체가 테뉴어드 세대를 어지럽히지 않도록 풀 GC 빈도를 줄일 수 있다.
  • 수집기가 라이브 반구를 수집할 때 객체들은 다른 반구로 압착시켜 옮기고 수집된 반구는 비워서 재사용한다.
  • 절반의 공간은 항상 완전히 비운다.
• 핫스팟에서는 영 힙의 반구부를 서바이버 공간이라고 한다.

6.5 병렬 수집기

• 자바 8 이전까지 JVM 디폴트 GC는 병렬 수집기(parallel collector)이다.
  • 처리율에 최적화되어 있고 영 GC, 풀 GC 모두 풀 STW를 일으킨다.
  • STW 후 CPU 코어를 총동원해 빠르게 메모리를 수집한다.
• 병렬 수집기 종류
  • Parallel GC: 가장 단순한 영 세대용
  • ParNew GC: CMS 수집기와 함께 사용할 수 있게 Parallel GC를 조금 변형한 것 (자바 8 기준 디폴트 올드 세대 수집기)
  • ParallelOld GC: 올드 세대용

6.5.1 영 세대 병렬 수집

• 스레드가 객체를 할당할 때 TLAB 공간은 부족하고 JVM이 새 TLAB를 할당할 수 없을 때 영 세대 수집이 발생한다.
  1. STW가 발생
  2. 핫스팟은 GC 루트에서 출발하여 에댄 및 서바이버 공간을 뒤져 가비지가 아닌 객체를 찾는다.
  3. Parallel GC는 살아남은 객체를 비어 있는 서바이버 공간으로 모두 방출 후 세대 카운트를 늘린다.
  4. 비워진 서바이버 공간을 재사용 가능한 공간으로 표시하고 STW를 멈춘다.
  5. TLAB를 애플리케이션 스레드에 배포하는 프로세스를 재개한다.
• 영 병렬 수집기는 살아있는 객체를 탐색하고 서바이버로 옮기는 과정에서 죽은 객체는 절대 건드리지 않는다.
  • 마킹 시간은 생존 객체 수에 비례

6.5.2 올드 세대 병렬 수집

• ParallelOld GC는 서바이버 공간을 활용하는 Parallel GC와 달리 하나의 연속된 메모리 공간에서 압착하는 수집기이다.
• 올드 세대가 가득 차면 병렬 수집기는 올드 세대 내부 객체들을 재배치해서 늙은 객체가 죽고 빠진 공간을 회수한다.
  • 효율적이고 단편화가 일어나지 않는다.
  • 풀 GC 내내 CPU를 점유
• 올드 공간을 영 공간에 비해 메모리 할당 및 소거 같은 눈에 띄는 변화가 크게 없다.
  • 풀 GC가 일어나 재배치될 때만 변한다.

6.5.3 병렬 수집기의 한계

• 병렬 수집기는 전 세대를 대상으로 효율적으로 가비지를 수집하지만 단점도 있다.
• 풀 STW를 유발
  • 영 GC는 큰 영향이 없지만 풀 GC에서 STW 영향이 매우 크다.
  • STW 시간은 힙 크기에 거의 비례한다.
  • 영역 내 살아 있는 객체 수만큼 마킹 시간이 늘어나는데 올드 세대는 영 세대의 약 7배의 크기

• 자바는 손쉽게 스레드를 생성할 수 잇지만 새 스레드는 곧 실행 스택을 의미하고 실행 스택의 각 프레임은 GC 루트의 원천이므로 GC는 더 복잡해진다.

    public static void main(String[] args) {
        int[] anInt = new int[1];
        anInt[0] = 42;
        new Thread(() -> anInt[0]++).start();
    }
  

  • 위 코드에서 anInt는 메인 스레드 관할 TLAB에 할당되지만 곧바로 새로운 스레드로 넘어간다.
  • 즉 하나의 스레드에 귀속되는 TLAB의 특성은 할당에서만 그렇고 그 이후엔 깨질 수 있다.

6.6 할당의 역할

• GC 사이클은 하나 이상의 힙 메모리 공간이 꽉 채워져 더 이상 객체를 생성할 공간이 없을 때 일어난다.
  • 고정된 일정이 아닌 그때그때 필요에 의해 발생
  • 불확정적, 불규칙적
• GC가 발생하면 모든 애플리케이션 스레드가 멈추고 JVM은 모든 코어를 동원해 메모리를 회수한다.
• 영 GC만 일어난다면 이상적이겠지만 약한 세대별 가설에 따르면 객체 수명은 불확실한 분포를 보여 결국 일부는 테뉴어드에 도달한다.
• 메모리 사용 패턴이 단순 톱니형으로 표시되면 힙을 효율적으로 사용하는 패턴이다.
• 할당률은 갑자기 치솟기도 하는데 할당률이 높으면 GC는 더 자주 실행되고 객체는 테뉴어드로의 승격이 빨라질 것이다.
  • 할당률이 낮아 GC가 덜 일어나면 서바이버 공간을 맴돌다 사라지겠지만 자주 일어난 GC는 세대 카운트를 빠르게 증가시켜 테뉴어드로 보내버리게 된다.
  • 이 현상을 조기 승격이라고 한다.