[REVIEW] JVM 밑바닥까지 파헤치기 - 3.1 가비지 컬렉터와 메모리 할당 전략

프로그램 카운터, 가상 머신 스택, 네이티브 메서드 스택은 스레드와 함께 생성되고 소멸된다. 또한 메서드에 진입하고 나올 때는 스택 메모리에 스택 프레임을 푸시하고 팝 한다. 각 스택 프레임에 할당되는 메모리 크기는 기본적으로 클래스가 만들어질 때 결정된다. 따라서 이 영역의 메모리 할당과 회수는 어떻게 회수할지는 고민하지 않아도 된다. 메서드가 끝나거나 스레드가 종료되면 자연스럽게 회수될 것이다. 

 

반면 자바 힙과 메서드 영역은 구현한 클래스마다 요구하는 메모리 크기가 다를수 있으며, 어떤 조건 분기를 실행하느냐에 따라 메모리 요구량이 달라질 수 있다. 프로그램이 어떤 객체를 생성할지, 얼마나 많이 만들지는 오직 런타임에만 알 수 있다. 그래서 이 메모리 영역들의 할당과 회수는 동적으로 이루어진다. 가비지 컬렉터는 바로 이런 영역을 관리하는데 집중한다. 

 

자바는 거의 모든 객체 인스턴스를 힙에 저장한다. 가비지 컬렉터는 어떤 객체가 살아있고, 죽었는지를 판단한 후, 힙을 청소한다.

 

그럼 어떻게 객체가 살아있는지, 죽어있는지 판단할수 있을까?

대표적으로 참조 카운팅을 사용하여 판단한다고 생각하지만 자바 가상 머신은 참조 카운팅을 쓰지 않는다.

 

참조 카운팅
1. 객체가 가리키는 참조 카운터(reference counter)를 추가한다. 참조하는 곳이 하나 늘어날 때마다 카운터 값을 1씩 증가시킨다.
2. 참조하는 곳이 하나 사라질 때마다 카운터 값을 1씩 감소시킨다.
3. 카운터 값이 0이 된 객체는 더는 사용할 수 없다.

 

예를 들어,  순환 참조 문제를 참조 카운팅만으로 해결하기 어렵다. 예를 들어, 순환 참조같은 문제는 서로 참조하고 있기 때문에 참조 카운터는 0이 안되는 문제로 참조 카운팅 알고리즘으로는 둘을 회수하지 못한다. 

 

 

도달 가능성 분석 알고리즘

자바는 객체 생사 판단에 도달 가능성 분석 알고리즘을 이용한다. 이 알고리즘의 기본 아이디어는 GC 루트라고 하는 루트 객체들을 시작 노드 집합으로 쓰는 것이다. 시작 노드들에서 출발하여 참조하는 다른 객체들로 탐색해 들어간다. 탐색 과정에서 만들어지는 경로를 참조 체인이라 한다. 그리고 어떤 객체와 GC 루트 사이를 이어주는 참조 체인이 없다면, 즉 GC 루트로부터 도달 불가능한 객체는 더 이상 사용할 수 없는 게 확실해진다. 객체들이 서로 이어져 있지만 GC 루트로부터 도달할 길이 없으면 회수 대상이 된다. 

 

자바에서 GC 루트로 이용할 수 있는 객체는 정해져있다.

• 가상 머신 스택(스택 프레임의 지역 변수 테이블)에서 참조하는 객체
  • 현재 실행 중인 메서드에서 쓰는 매개 변수, 지역 변수, 임시 변수 등
• 메서드 영역에서 클래스가 정적 필드로 참조하는 객체
  • 자바 클래스의 참조 타입 정적 변수
• 메서드 영역에서 상수로 참조되는 객체 
  • 문자열 테이블 안의 참조
• 네이티브 메서드 스택에서 JNI(네이티브 메서드)가 참조하는 객체
• 자바 가상 머신 내부에서 쓰이는 참조
  • 기본 데이터 타입에 해당하는 Class 객체
  • NullPointerException, OutOfMemoryError 등의 일부 상주 예외 객체
  • 시스템 클래스 로더
• 동기화 락(synchronized)으로 잠겨 있는 모든 객체
• 자바 가상 머신 내부 상황을 반영하는 JVMTI에 등록된 콜백, 로컬 코드 캐시 등

객체는 다른 영역에 있는 객체도 참조할 수 있으므로 연관된 영역의 객체들도 GC 루트 집합에 포함시켜야 도달 가능성을 정확하게 분석할 수 있다. 

 

 

참조

객체의 생사 판단과 '참조'는 분리해서 생각할 수 없다. JDK 1.2부터 참조 개념이 확장되어 참조를 네 가지로 구분한다.

 

• 강한 참조(strong reference)
  • 가장 전통적인 정의의 참조
  • Object obj = new Object()처럼 프로그램 코드에서 참조를 할당을 뜻함
  • 강한 참조 관계가 남아있는 객체는 가비지 컬렉터가 절대 회수하지 않는다.
• 부드러운 참조(soft reference)
  • 유용하지만 필수가 아닌 객체
  • 메모리 오버플로가 나기 직전에 두 번째 회수를 위한 회수 목록에 추가된다.
  • 두번째 회수 후에도 메모리가 부족하면 그때 메모리 오버플로 예외를 던진다. 
• 약한 참조(weak reference)
  •  부드러운 참조보다 연결 강도가 더 약하다.
  • 다음번 가비지 컬렉션까지만 살아있고, 가비지 컬렉터가 동작하기 시작하면 메모리가 넉넉하더라도 약하게 참조된 객체는 모두 회수된다.
• 유령 참조(phantom reference)
  • 객체 수명에 영향을 주지 않는다.
  • 유령 참조를 통해 객체 인스턴스를 가져오지 못한다.
  • 유일한 목적은 대상 객체가 회수될 때 알림을 받기 위해서다.

 

살았나 죽었나?

도달 가능성 분석 알고리즘이 '도달 불가능'으로 판단한 객체는 반드시 죽은 객체는 아니고 두 번의 표시 과정을 거쳐야 한다.

도달 가능성 분석으로 GC 루트와 연결된 참조 체인을 찾지 못한 객체에는 첫 번째 표시가 이루어지며 필터링이 진행된다. 필터링 조건은 종료자(finalizer), 즉 'finalize() 메서드를 실해해야 하는 객체인가'이다. finalize()가 필요 없는 개체이거나 가상 머신이 finalize()를 이미 호출한 경우 모두 '실행할 필요 없음'으로 처리한다.

 

finalize()를 실행해야 하는 객체는 F-큐(F-Queue)라는 대기열에 추가된다. 그럼 가상 머신이 나중에 우선순위가 낮은 종료자 스레드를 생성해 F-큐에 들어있는 객체들의 finalize() 메서드를 실행한다. 가상머신은 이 메서드를 시작만 할 뿐 종료될 때까지 기다리지 않는다. 

만약 객체가 finalize()를 이용하여 참조 체인상의 아무 객체와 연결되면 두 번째 표시 과정에서 '회수 대상' 목록에서 제외된다.

 

하지만 finalize()은 실행하는 비용도 높고 불확실성도 크므로 가능한 한 사용하지 않는 게 좋다.

 

 

메서드 영역 회수하기

<자바 가상 머신 명세>에 따르면 가비지 컬렉터가 메서드 영역을 반드시 청소해야 하는 건 아니다. 가비지 컬렉션 한 번으로 자바 힙의 메모리 공간을 70~90% 를 회수하는 반면, 메서드 영역은 회수 조건이 까다로워서 대체로 '비용 효율'이 좋지 않다.

 

메서드 영역의 가비지 컬렉션은 더 이상 사용되지 않는 '상수'와 '클래스'를 회수한다. 상수가 참조하는 객체가 없고, 가상 머신에서 이 상수를 사용하는 코드가 없다면 회수한다. 하지만 더 이상 쓰이지 않는 '클래스'를 판단할 때는 다음 세 조건을 동시에 만족해야 한다.

• 이 클래스의 인스턴스가 모두 회수되었다. 즉, 자바 힙에는 해당 클래스와 하위 클래스의 인스턴스가 하나도 존재하지 않는다.
• 이 클래스를 읽어 들인 클래스 로더가 회수되었다. 이 조건은 OSGi 나 JSP 리로딩처럼 세심하게 설계된 대안 클래스 로더 없이는 충족하기 어렵다.
• 이 클래스에 해당하는 java.lang.Class 객체를 아무 곳에서 참조하지 않고, 리플렉션 기능으로 이 클래스의 메서드를 이용하는 곳도 전혀 없다.

자바 가상 머신은 세 조건에 부합하는 쓸모없는 클래스들을 회수하도록 허용한다. 

핫스팟 가상 머신은 클래스 회수 여부를 제어할 수 있도록 -Xnoclassgc 매개변수를 제공한다. 또한 -verbose:class, -Xlog:class+load=info, -Xlog:class_unload=info 매개변수로는 클래스가 로딩되고 언로딩 되는 정보를 볼 수 있다.

 

---

 

가비지 컬렉션 알고리즘

가비지 컬렉션 알고리즘을 구현하는 데는 수많은 기법이 활용되며 가상 머신 또는 플랫폼에 따라 차이가 많다.

객체의 생사를 판별하는 방식을 기준으로 가비지 컬렉션 알고리즘을 '참조 카운팅 GC (직접 가비지 컬렉션)'와 '추적 GC (간접 가비지 컬렉션)'로 나눌 수 있다. 

 

세대 단위 컬렉션 이론

현재 상용 가상 머신들이 채택한 가비지 컬렉터는 대다수 프로그램에서 관측된 실제 상황들에서 얻은 경험 법칙을 구현한 세대 단위 컬렉션 이론에 기초해 설계되었다.  기본적으로 두 가정이 뿌리를 이룬다.

1. 약한 세대 가설: 대다수 객체는 일찍 죽는다.
2. 강한 세대 가설: 가비지 컬렉션 과정에서 살아남은 횟수가 늘어날수록 더 오래 살 가능성이 커진다.

이 두 가정이 합쳐져 가비지 컬렉터들에 일관된 설계 원칙을 제공한다. 자바 힙을 몇 개의 영역으로 나누고 객체들을 나이에 따라 각기 다른 영역에 할당하는 것이다. 여기서 나이란 가비지 컬렉션에서 살아남은 횟수를 말한다. 영역 안의 객체 대부분이 곧바로 죽을 운명이라면 그 개게들을 한데 몰아넣고 살아남는 소수의 객체를 유지하면, 가비지 컬렉션에 드는 전체 시간도 줄고 메모리 공간도 효율적으로 이용할 수 있다.

 

자바 힙을 여러 영역으로 나누면 가비지 컬렉터는 한 번에 하나 또는 몇 개의 영역만 선택해 회수할 수 있는데 이를 기준으로 마이너 GC, 메이저 GC, 전체 GC로 부른다.

 

• 부분 GC : 자바 힙의 일부만 회수하는 가비지 컬렉션을 말하며 다음과 같이 세분화된다.
  • 마이너 GC(신세대 GC) : 신세대만 대상으로 하는 가비지 컬렉션
  • 메이저 GC(구세대 GC) : 구세대만 대상으로 하는 가비지 컬렉션. 집필 시점 기준으로 오직 CMS 컬렉터만 구세대를 따로 회수한다. 
  • 혼합 GC : 신세대 전체와 구세대 일부를 대상으로 하는 가비지 컬렉션. 집필 시점 기준으로 G1 컬렉터만 이렇게 동작한다.
• 전체 GC : 자바 힙 전체와 메서드 영역까지 대상으로 하는 가비지 컬렉션

 

마크-스윕 알고리즘

작업을 표시(mark)와 쓸기(sweep) 두 단계로 진행한다. 먼저 회수할 객체들을 모두 표시한 다음, 표시된 객체들을 담는다. 반대로 살릴 객체에 표시되지 않은 객체를 회수한다. 

 

단점

• 실행 효율이 일정하지 않다. 자바 힙에 객체가 많고 대부분이 회수 대상이면 표시하는 일과 회수하는 일이 커진다. 즉 객체가 많아질수록 표시하고 쓸어 담는 작업의 효율이 떨어진다.
• 메모리 파편화가 심하다. 가비지 컬렉터가 쓸고 가면 불연속적인 메모리 파편이 만들어진다. 파편화가 너무 심하면 프로그램이 큰 객체를 만들려 할 때 충분한 크기의 연속된 메모리를 찾기가 어려워지고, 그 결과 또 다른 가비지 컬렉션을 유발한다.

 

마크-카피 알고리즘

가용 메모리를 똑같은 크기의 두 볼록으로 나눠 한 번에 한 블록만 사용하고 한쪽 블록이 꽉 차면 살아남은 객체들만 다른 블록에 복사하고 기존 블록을 한번에 청소한다.  오늘날 사용 자바 가상 머신 대부분은 신세대에 이 알고리즘을 활용한다. 

 

장점

• 이 알고리즘은 구현하기 쉽고 실행 효율도 좋다. 

단점

• 가용 메모리를 절반으로 줄여 낭비가 심하다.

 

즉, 객체 생존율이 높을수록 복사할게 많아져서 효율이 나빠지고, 공간을 낭비하는 것을 대체하기 위해 하당 보증용 공간을 마련하여 대다수 객체가 살아남는 극단적 상황에 대처해야 한다.

 

 

아펠 스타일 컬렉션

핫스팟 가상 머신의 신세대 컬렉터는 모두 신세대 메모리의 레이아웃을 이 전략에 부합하게 구성한다.

아펠 스타일 컬렉션 방식은 신세대를 하나의 큰 에덴 공간과 두 개의 작은 생존자 공간으로 나누고, 메모리를 할당할 때는 생존자 공간 중 하나와 에덴만 사용한다. 가비지 컬렉션이 시작되면 에덴과 생존자 공간에서 살아남은 객체들은 나머지 생존자 공간으로 하나씩 복사한 후 에덴과 이전 생존자 공간을 곧바로 비운다. 아펠 스타일 컬렉션은 낭비하는 공간을 대처하기 위해 메모리 할당 보증 메커니즘을 추가하였는데, 이 메커니즘은 마이너 GC에서 살아남은 객체를 생존자 공간이 다 수용하지 못할 경우 다른 메모리 영역을 활용해 메모리 할당을 보증한다. 

 

 

마크-컴팩트 알고리즘

표시 단계는 마크-스윕과 같다. 하지만 다음 컴팩트 단계에서 회수 대상 객체들을 곧바로 쓸어 담는 대신, 생존한 모든 객체를 메모리 영역의 한쪽 끝으로 모은 다음, 나머지 공간을 한꺼번에 비운다.  마크-스윕과의 차이점은 메모리 이동이 일어난다. 구세대에서는 회수 때마다 살아남는 객체가 많아 생존한 객체를 이동시킨후, 이동된 객체들을 가리키던 기존 참조들을 모두 갱신하기 어렵다. 

 

메모리 할당과 접근에 부담을 많이 더하지 않는 방식은 대부분의 경우, 메모리 파편화를 감내하면서 마크-스윕을 사용하다가, 객체 할당에 양향을 줄 만큼 파편화가 심해지면 마크-컴팩트를 돌려 연속된 공간을 확보하는 것이다. CMS는 마크-스윕을 기본으로 하며, 메모리 파편화가 심해지면 이 전략을 실행하여 단점을 보완한다.

 

---

 

핫스팟 알고리즘 상세 구현

효율적인 가상 머신을 만들려면 각 알고리즘의 실행 효율을 따져봐야 한다. 다양한 가비지 컬렉터를 소개할 것이며, 필요한 기초 지식을 소개한다.

 

루트 노드 열거

'효율적인 가상 머신 구현하기'의 첫 번째 예로는 루트 노드 열거이다.

• 도달 가능성 분석 알고리즘에서 GC 루트 집합으로부터 참조 체인을 찾는 작업
• GC 루트로 고정할 수 있는 노드는 주로 전역 참조(상수와 클래스 정적 속성 등)와 실행 콘텍스트(스택 프레임의 지역 변수 테이블 등)에 존재한다.

오늘 날의 자바 애플리케이션은 거대해지고 있어, 모든 참조를 확인하려면 시간이 많이 소요된다. 지금까지 모든 컬렉터는 루트 노드 열거 단계에서 사용자 스레드를 일시 정지해야 했다. 하지만 현재 도달 가능성 분석 알고리즘의 참조 체인 찾기 과정에서 가장 오래 거리는 작업은 다행히도 사용자 스레드와 동시에 실행할 수 있다. 단, 반드시 일관성이 보장되는 스냅숏 상태에서 수행해야 한다. 여기서의 일관성이란 열거 작업이 진행되는 동안 루트 노드들의 참조 관계가 변하지 않아야 한다. 현재 주류 자바 가상 머신들은 '정확한 가비지 컬렉션을 사용하는데 이는 정확한 메모리 관리 기술을 적용한 가비지 컬렉션을 말한다. 사용자 스레드가 정지한 후 실행 콘텍스트와 전역 참조의 위치를 빠짐없이 확인할 필요가 없다. 그 대신 가상 머신이 객체 참조가 저장된 위치를 직접 알아낼 방법이 있어야 한다.

 

핫스팟은 0opMap 데이터 구조를 이용해 클래스 로딩이 완료되면 객체에 포함된 각 데이터의 타입을 확인한 후, JIT 컴파일 과정에서 스택의 어느 위치와 어느 레지스터의 데이터가 참조인지 기록하여 이 문제를 해결한다. 컬렉터는 메서드 영역과 다른 GC 루트들을 추적해보지 않고 스캔 과정에서 이 정보를 직접 얻어낸다.

 

 

안전 지점

핫스팟은 0opMap을 활용하여 GC 루트들을 빠르고 정확하게 열거할 수 있다. 하지만 참조 관계나 0opMap의 내용을 변경할수 있는 명령어가 많으면, 명령어 모두 0opMap을 만들어 놓으면 메모리를 더 많이 사용해야한다. 그래서 핫스팟은 모든 명령어 각각에 0opMap을 생성하지 않고 안전 지점이라고 하는 특정한 위치에만 기록한다. 가비지 컬렉터는 사용자 프로그램이 안전 지점에 도달할 때까지는 절대 멈추지 않는다. 따라서 안점 지점을 너무 적게 설정해서 컬렉터가 너무 오래 기다리게 하거나, 반대로 너무 많이 설정해서 런타임 메모리 부하가 커지지 않도록 주의해야 한다.

 

안전 지점의 위치를 선택하는 기준은 '프로그램이 장시간 실행될 가능성이 있는가'이다. '장시간  실행'될 가능성을 보옂우는 상황은 명령어 흐름이 다중화 될때인데, 메서드 호출, 순환문, 예외 처리 등 명령어 흐름을 다중화하는 예이며, 이런 기능을 하는 명령어만이 안점 지점을 생성한다. 

 

또한 추가적으로 안전 지점과 관련하여 고려해야 할 무네는 가비지 컬렉션이 시작되면 JNI 호출을 실행 중인 스레드를 제외한 모든 스레드가 가장 가까운 안전 지점까지 실행하고 멈추게 할 방법이 필요한데, 선제적 멈춤과 자발적 멈춤이 있다.

 

선제적 멈춤(preemptive suspension)

• 스레드의 코드가 가비지 컬렉터를 특별히 신경 쓸 필요가 없다.
• 가비지 컬렉션이 실행되면 시스템이 모든 사용자 스레드를 인터럽트 하여, 사용자 스레드가 중단된 위치가 안전 지점이 아니라면 스레드를 재개하고 안전 지점에 도달할 때까지 인터럽트를 반복한다.
• 하지만 가비지 컬렉션에 선제적 멈춤 방식을 이용하는 가상 머신은 거의 없다.

자발적 멈춤(voluntary suspension)

• 가비지 컬렉터가 스레드 수행에 직접 관여하지 않는다.
• 플레그 비트를 설정하고, 각 스레드가 실행 중에 플래그를 적극적으로 폴링 한다. 플래그 값이 true 이면 가장 가까운 안전 지점에스 스스로 멈춘다.
• 폴링 플래그들은 안전 지점에 위치한다.
• 객체 생성 등 자바 힙 메모리를 소비하는 장소에도 폴링 플래그가 추가된다. 메모리가 부족해 새로운 객체를 할당하지 못하는 일을 예방하기 위해 적절한 시점에 가비지 컬렉션을 수행하기 위함이다.
• 폴링은 코드에서 자주 일어나므로 효율적 이여야 한다. 핫스팟은 메모리 보호 트랩이라는 방법을 써서 어셈블리 명령아 하나만으로 수행할 수 있게 단순화했다.

 

안전 지역

안전 지점 메커니즘은 실해 중인 프로그램이 짧은 시간에 안전 지점에 도달하여 가비지 컬렉션 프로세스가 제대로 임무를 다할 수 있게끔 보장하지만, 실행 중이 아닌 프로그램의 스레드들은 가상 머신의 인터럽트 요청에 응답할 수 없고, 안전 지점까지 수행한 후 인터럽트되어 스스로를 일시 정지 시킬 수 없다. 또한 스레드가 다시 활성화되어 프로세서를 할당 받을때까지 가상 머신이 기다리지 않는다. 실행 중이 아닌 프로그램이란 프로세서를 할당받지 못한 프로그램이며, 일반적으로 잠자기 상태이거나 블록된 상태의 사용자 스레드이다. 이런 경우를 위해 안전 지역이라는 개념이 필요하다.

 

안전 지역은 일정 코드 영역에서는 참조 관계가 변하지 않음을 보장한다. 안전 지역 안이라면 어디서든 가비지 컬렉션을 시작해도 무방하다는 뜻이다. 사용자 스레드는 안전 지역의 코드를 실행하기 앞서 안전 지역에 진입했음을 표시하면, 가비지 컬렉터는 이 스레드들을 신경 쓰지 않는다. 안전 지역에서 벗어나려는 스레드는 가상 머신이 루트 노드 열거를 완료했는지 또는 사용자 스레드를 일시 정지시켜야 하는 다른 가비지 컬렉션 단계를 완료했는지 확인한다.

 

 

기억 집합과 카드 테이블

가비지 컬렉션 시 컬렉터는 기억 집합을 이용해 특정 비회수 영역에서 회수 영역을 가리키는 포인터만 존재하는지만 확인하면 된다. 세대 간 포인터들 각각에 대해 더 이상 자세한 내용을 알 필요는 없다. 따라서 기억 집합 설계자는 정밀도를 낮춰서, 즉 기록 단위를 더 크게 잡아서 공간과 관리 비용을 절약할 수 있을 것이다. 

• 카드 정밀도
  • 레코드 하나(카드)가 메모리 블록 하나에 매핑된다. 특정 레코드가 마킹되어 있다면, 해당 블록에 세대 간 참조를 지닌 객체가 존재한다는 뜻이다.

기억 집합은 사실 '추상' 데이터 구조다. 카드 정밀도로 기억 집합을 구현한 것을 카드 테이블이라 한다. 카드 테이블은 기록 정밀도와 힙 메모리의 매핑 관계 등을 정의하여 기억 집합을 구체적으로 구현한 방법 중 하나다. 카드 페이지 하나의 메모리에는 보통 하나 이상의 객체가 들어 있다. 이 객체들 중 하나라도 세대 간 포인터를 갖는 필드가 있다면, 카드 테이블에서의 해당 원소를 1로 표시하고, 그 원소는 더럽혀졌다라고 말한다. 세대 간 포인터를 갖는 객체가 하나도 없다면 0으로 표시된다. 그리고 객체를 회수할 때는 카드 테이블에서 더럽혀진 원소만 확인하면 어떤 카드 페이지의 메모리 블록이 세대 간 포인터를 포함하는지 쉽게 파악할 수 있다. 이런 식으로 세대 간 참조를 포함한 블록만 GC 루트에 추가해 함께 스캔한다. 이렇게 기억 집합을 이용해 GC 루트의 스캔 범위를 줄이는 문제를 해결한다.

 

 

쓰기 장벽

카드 테이블의 원소는 다른 세대의 객체가 현 블록 안의 객체를 참조하면 카드 테이블의 해당 원소는 더럽혀진다. 더럽혀지는 시점은 참조 타입 필드에 값이 대입되는 순간이다.

핫스팟 가상 머신은 쓰기 장벽 기술을 이용해 카드 테이블을 관리한다.

• 읽기 장벽은 동시 비순차 실행 문제를 해결하기 위한 메모리 장벽 기술이다. 
• 쓰기 장벽은 가상 머신 수준에서 '참조 타입 필드 대입'시 끼어드는 AOP 애스팩트(aspect)에 비유할 수 있다. 참조타입에 객체가 대입되면 어라운드 어드바이스가 생성되어, 대입 전후로 추가 동작을 수행할 수 있게 한다. 이런 기능 모두를 쓰기 장벽으로 구현할 수 있다. 대입 전 쓰기 장벽을 사전 쓰기 장벽이라 하며, 대입 후 쓰기 장벽을 사후 쓰기 장벽이라 한다. 핫스팟 가상 머신의 컬렉터 다수가 쓰기 장벽을 이용한다. 
• 쓰기 장벽을 적용하면 가상 머신은 추가로 실행할 명령어를 생성해 대입 연산 모두에 추가한다. 컬렉터가 쓰기 장벽으로 카드 테이블 갱신 연산을 추가한다면 참조가 갱신될 때마다 오버헤드가 더해진다.
• 카드 테이블은 멀티스레드 시나리오에서 거짓 공유(false sharing) 문제를 일으킬 수 있다.
  • 거짓 공유(false sharing)
    • 거짓 공유는 낮은 수준에서 동시성을 다룰  때 고려해야 하는 문제다. CPU의 캐시 시스템은 데이터를 캐시 라인 단위로 관리한다. 여러 스레드가 서로 다른 변수를 수정하는 상황에서 그 변수들이 같은 캐시 라인에 저장되어 있다면 라이트백(write back), 무효화, 동기화 등의 작업 시 서로 영향을 주어 성능을 떨어뜨린다. 실제로 공유하고 있지 않음에도 마치 공유하는 것처럼 서로 영향을 준다고 하여 이를 거짓 공유 문제라고 한다.
• JDK 7부터 핫스팟 가상 머신은 -XX:+UserCondCrdMark 매개변수를 추가하여 카드 테이블 갱신 시 조건을 판단할 수 있게 한다. 이 매개 변수를 설정하면 조건을 판단하는 오버헤드가 더해지지만, 거짓 공유 문제는 피할 수 있다.

 

동시 접근 가능성 분석

현재 주류 프로그래밍 언어의 가비지 컬렉터들은 기본적으로 도달 가능성 분석 알고리즘을 써서 객체의 생사를 판단한다. 이론적으로 도달 가능성 분석 알고리즘은 일관성이 보장되는 스냅숏 상태에서, 즉 사용자 스레드는 분석 과정 중 멈춰있는 상태에서 전체 과정을 진행해야 한다. 

루트 노드 열거가 끝나면 가비지 컬렉터는 GC 루트로부터 객체 그래프를 탐색할 수 있다. 이 단계의 일시 정지 시간은 자바 힙 크기에 비례한다. 힙이 클수록 더 많은 객체를 담게 되고 객체 그래프 구조도 복잡해진다. 

참조 관계를 추적하는 가비지 컬렉션 알고리즘들에는 공통적으로 '표시'단계가 등장한다. 표시 단계의 일시 정지 시간이 힙 크기에 비례해 증가한다면 거의 모든 가비지 컬렉터에 악영향을 준다. 즉, 이 단계의 일시 정지 시간을 줄이면 순영향을 준다.

 

 

삼색 표시(tri-color marking)

객체 그래프를 여행하는 과정에서 마주치는 객체들에 '방문한 객체'인가 라는 조건에 따라 아래 세 가지 색 중 하나를 칠하는 기법이다.

• 흰색: 가비지 컬렉터가 방문한 적 없는 객체인 경우. 도달 가능성 분석을 시작하면 모든 객체는 흰색이다. 분석을 마친 뒤에도 흰색인 객체는 도달 불가능함을 뜻한다.
• 검은색: 가비지 컬렉터가 방문한 적이 있으며, 이 객체를 가리키는 모든 참조를 스캔했다. 스캔되었고, 생존하면 검은 객체가 된다. 다른 객체에서 검은 객체를 가리키는 참조가 있다면 다시 스캔하지 않아도 된다. 검은 객체가 흰 객체를 바로 가리키는 건 불가능하다. 회색 객체를 거쳐 가리킬 수 있다.
• 회색: 가비지 컬렉터가 방문한 적 있으나, 이 객체를 가리키는 참조 중 스캔을 완료하지 않은 참조가 존재한다.

삼색 표시 기법의 장점

• 인크리멘털(Incremental) GC 가능
  • 전체 프로그램을 멈추지 않고(Stop-the-world 최소화) 점진적으로 수행할 수 있다.
• 병렬(Concurrent) GC 가능
  • 여러 스레드에서 병렬로 가비지 컬렉션이 가능해서 성능이 좋아진다.
• 안전성(Safety) 확보
  • 흑색(Black) 객체가 흰색(White) 객체를 직접 참조하는 경우가 없음 → 가비지 컬렉션 중 메모리 정합성을 유지할 수 있다.

 

만약 사용자 스레드와 컬렉터가 동시에 실행되면, 발생하는 문제점

1. 죽은 객체를 살았다고, 잘못 표시할 수 있다.
2. 살아 있는 객체를 죽었다고 표시할 수 있다. 치명적이며, 프로그램 오류로 이어진다.

 

아래 두 조건이 동시에 만족될 때만 객체 사라짐 문제가 나타난다.

• 사용자 스레드가 흰색 객체로의 새로운 참조를 검은색 객체에 추가
• 사용자 스레드가 회색 객체에서 흰색 객체로의 직간접적인 참조를 삭제

동시 스캔 도중 객체 사라짐 문제를 해결하려면 두 조건 중 하나만 만족하면 된다. 

해법은 증분 업데이트와 시작 단계 스냅숏(snapshot at the beginning)이 있다.

 

• 증분 업데이트 (Incremental Update)
  • 검은색 객체에 흰색 객체로의 참조가 추가되면 새로 추가된 참조를 따로 기록해 두어, 동시 스캔이 끝난 후 기록해 둔 검은색 객체들을 루트로 하여 다시 스캔한다. 
  • GC가 루트 객체(root set)부터 점진적으로 객체 그래프를 탐색하면서 업데이트하는 방식.
  • 탐색 중에도 애플리케이션이 객체의 참조를 변경할 수 있음, 그래서 변경 사항을 즉시 반영해야 함.
  • 이를 위해 Write Barrier(쓰기 방벽) 기술을 사용하여 새로운 참조를 즉시 회색(Gray)으로 변경함.
  • 장점:
    • Stop-the-world 시간을 줄일 수 있음 (애플리케이션과 GC가 병렬로 실행 가능).
    • 최신 변경 사항을 계속 반영하므로 더 적은 가비지가 떠다님(Floating Garbage 감소).

• 시작 단계 스냅숏 (Snapshot at the Beginning, SATB)
  • 회색 객체가 흰색 객체호의 참조 관계를 끊으려 하면 그 사실을 기록하며, 동시 스캔이 끝난 후 기록해 둔 회색 객체들을 루트로 하여 다시 스캔한다.  
  • GC가 마킹을 시작하는 순간의 객체 그래프 상태를 유지하는 방식.
  • 애플리케이션이 마킹 중에 참조를 변경하더라도, 마킹 시작 시점의 참조 상태를 기준으로 가비지를 판별함.
  • 새로운 객체가 추가되더라도 기존에 흰색(White)으로 표시된 객체는 유지, 나중에 다시 탐색하지 않음.
  • 장점:
    • 마킹 시작 시점의 상태를 기준으로 하기 때문에 예측 가능한 동작을 보장함.
    • 정합성을 유지하면서 인크리멘털 GC 수행 가능.

 

증분 업데이트 (Incremental Update) 시작 단계 스냅숏 (SATB) 비교

방식	실시간으로 참조 변경 반영	마킹 시작 시점 기준 유지
Write Barrier 역할	새로운 참조를 회색으로 변경	기존 참조를 유지
Floating Garbage	적게 발생	상대적으로 많이 발생
Stop-the-world 시간	짧음	상대적으로 길어질 수 있음

 

 

가상 머신은 쓰기 장벽을 이용해 기록 작업을 구현한다. 핫스팟 가상 머신은 증분 업데이트와 시작 단계 스냅숏을 모두 활용한다. 메모리를 다시 확보하는 구체적인 방법은 가상 머신이 사용하는 가비지 컬렉터에 따라 다르며, 일반적으로 가상 머신은 다수의 가비지 컬렉터를 제공한다.

 

 

 

 

 

 

 

 

 

참고

https://product.kyobobook.co.kr/detail/S000213057051

JVM 밑바닥까지 파헤치기 | 저우즈밍 - 교보문고

 

https://lima1016.tistory.com/125

[JVM 밑바닥] 3장 가비지 컬렉터와 메모리 할당 전략 -1