여러 스레드가 한 객체에 동시에 접근할 때 어떤 런타임 환경에서든 다음 두 조건을 모두 충족하면서 객체를 호출하는 행위가 올바른 결과를 얻을 수 있다면 그 객체는 스레드 안전하다 라고 한다.

• 특별한 스레드 스케줄링이나 대체 실행 수단을 고려할 필요가 없다
• 추가적인 동기화 수단이나 호출자 측에서 조율이 필요 없다

스레드 안전성 단계

자바 스레드 안전성은 안전하다/안전하지 않다 두개로 나뉘지 않는다. 5가지 단계로 나눠 생각할 수 있어야 한다. (불변, 절대적 스레드 안전, 조건부 스레드 안전, 스레드 호환, 스레드 적대적)

불변

• 자바 final 키워드가 붙은 변수들이다.
• 이 변수들은 불변성이 지켜지므로, 스레드 안전하다.
• final 이 붙은 변수의 불변성은 자바 컴파일러와 JVM 이 지켜준다.
• Enum 타입, Long, Double, String, BigInteger, BigDecimal, java.lang.Number 하위 등 클래스들이 불변하다.

절대적 스레드 안전

• 위의 스레드 안전 정의를 만족하는 경우
• 자바 API 는 대부분 조건부 안전을 만족한다. 따라서 자바 API 를 사용하여 애플리케이션을 작성할 때 절대적 스레드 안전을 만들기 위해 synchronized, volatile 등 동기화 작업을 해야 한다.
• 동기화 작업이 완벽하게 된 메서드는 절대적 스레드 안전이라 할 수 있을 것이다.

조건부 스레드 안전

• 단일 작업은 스레드 안전하지만, 스레드 안전한 단일 작업을 n개 묶어서 사용할때에는 추가적인 동기화 처리가 필요한 경우
  • 메서드 자체는 synchronized 로 감싸 메서드 자체는 절대적 스레드 안전이지만, 절대적 스레드 안전 메서드 두개를 썼을때 스레드 불안전한 경우를 말한다.
• 자바에선 Vector, HashTable, SynchronizedCollections 등이 있다.

public class ThreadSafe {

    private static List<Integer> list = Collections.synchronizedList(new ArrayList<Integer>());

    static void main(String[] args) {
        while (true) {
            for (int i = 0; i < 10; i++) {
                list.add(i);
            }

            Thread removeThread = new Thread(() -> {
                for (int i = 0; i < list.size(); i++) {
                    list.remove(i);
                }
            });

            Thread printThread = new Thread(() -> {
                for (Integer integer : list) {
                    System.out.println(integer);
                }
            });

            removeThread.start();
            printThread.start();

            while (Thread.activeCount() > 20) ;
        }
    }
}

위 예시 코드에서 사용한 Collections.synchronizedList 는 add, remove 등 리스트에 가하는 메서드에 모두 synchronized 를 적용한다. 즉, 요소 수정 메서드 자체는 모두 절대적 스레드 안전이다.

하지만 위 예시는 ConcurrentModificationException 를 발생시키는 스레드 불안전 코드다. 위처럼 절대적 스레드 안전 메서드를 잘못 조합하면 문제가 생겨, 추가적인 동기화 처리가 필요한 경우를 조건부 스레드 안전 이라 한다.

추가적인 동기화 처리를 적용한 코드는 다음과 같다.

public class ThreadSafe {

    private static List<Integer> list = Collections.synchronizedList(new ArrayList<Integer>());

    static void main(String[] args) {
        while (true) {
            for (int i = 0; i < 10; i++) {
                list.add(i);
            }

            Thread removeThread = new Thread(() -> {
                synchronized(list) { // 추가됨
                    for (int i = 0; i < list.size(); i++) {
                        list.remove(i);
                    }
                }
            });

            Thread printThread = new Thread(() -> {
                synchronized (list) { // 추가됨
                    for (Integer integer : list) {
                        System.out.println(integer);
                    }
                }
            });

            removeThread.start();
            printThread.start();

            while (Thread.activeCount() > 20) ;
        }
    }
}

스레드 호환

• 객체 자체가 스레드 안전하지 않아 안전하게 사용하려면 동기화 처리를 해야 하는 클래스들
• 일반적인 ArrayList, HashMap 등등

스레드 적대적

• 동기화 조치를 취해도 멀티 스레드 환경에서 안전하게 사용할 수 없는 것들을 스레드 적대적이라 한다.
• 대표적으로 Thread.suspend(), Thread.resume()
  • JDK23 에서 사라졌다.
  • 동기화 블럭에서 Thread.suspend() 하면 락을 유지한 채로 스레드가 멈춘다. 스레드가 재게되어 로직을 모두 실행하고 락을 해제하기 전까지는 락을 필요로 하는 다른 스레드 모두 무기한 대기하게 된다.
  • 참고
• 이외에도 System.setIn(), System.setOut(), System.runFinalizersOnExit()

스레드 안전성 구현

자바에서 스레드 안전성을 실제로 구현하는 방법은 크게 3가지로 나눌 수 있다.

1. 상호 배제 동기화(Blocking 동기화)
2. Non-Blocking 동기화
3. 동기화 불필요 매커니즘

상호 배제 동기화(Blocking 동기화)

• synchronized
• ReentrantLock
• java.util.concurrent.Semaphore

synchronized, ReentrantLock 은 뮤텍스다. 뮤텍스는 공유 자원 하나에 대한 락이며, 락 해제는 락을 건 스레드만 가능하다. 세마포어는 n개의 리소스가 사용할 수 있는 잠금이며, 락의 소유 개념이 없어 다른 스레드가 허용 count 를 줄일 수 있다.

상호 배제 동기화의 비용

자바는 커널 스레드와 연결되는 1:1 스레드 모델이다. 상호 배제 락 때문에 스레드를 멈추거나 재개할 때에는 커널 모드로 전환하여 커널 스레드를 정지/재개해야 한다. 이는 상당히 비싼 비용의 작업이다.

synchronized

synchronzied 는 바이트 코드 명령어 monitorenter, monitorexit 를 사용한다.

monitorenter 는 객체의 모니터를 획득하려 시도하며, 다른 스레드에서 이미 락을 가지고 있다면 대기한다. 모니터를 획득한 스레드가 monitorexit 를 실행하면 대기중이던 스레드는 모니터를 획득하며 monitorenter 를 완료한다.

또한 같은 스레드라면 이미 모니터를 소유하고 있기 때문에 synchronized 블록에 다시 진입할 수 있다.

ReentrantLock

재진입 가능 락으로 synchronized 와 비슷하다. JDK 5 에 생긴 java.util.concurrent.locks.Lock 의 대표적 구현체다.

synchronized 에 비해 몇가지 추가 기능을 제공한다.

1. 대기중 인터럽트 : 대기 중 스레드가 너무 오래 걸리면 락 획득을 포기하고 다른 일을 할 수 있다.
2. 페어 락 : 같은 락을 얻기 위해 대기하는 여러 스레드에 대해 획득 시도 순서로 락을 획득하도록 할 수 있다.
   • 처리량에 큰 악영향이 있다. 사용에 주의
   • 대기 중인 스레드 중 우선순위 없이 랜덤으로 획득하는 것을 un-fair 락이라 한다. synchronized 는 un-fair 이며, ReentrantLock 는 선택할 수 있다.
3. 둘 이상의 조건 지정 : newCondition() 객체를 여러번 호출하여 여러 조건을 만들 수 있다.
   • synchronized 는 wait(), notifiy(), notifiyAll() 에 하나의 조건만 줄 수 있다.

synchronized vs ReentrantLock

현재는 두 키워드의 성능이 비슷하다.

ReentrantLock 는 finally 블록에서 락 해제를 반드시 해줘야 한다.

ReentrantLock 만의 기능이 필요한게 아니라면 락 획득과 해제를 자동으로 해주는 synchronized 가 더 좋을 것이다.

논블로킹 동기화

상호 배제 동기화는 상당이 큰 비용을 지불한다고 했다. 상호 배제 동기화는 비관적 동기화로서, 동기화하지 않으면 문제가 생김을 전제로 동작한다.

이 반대는 낙관적 동기화로, 문제가 생기지 않을 것 같으니 일단 실행한다.

1. 일단 작업 실행
2. 충돌 감지
3. 적절한 처리

대기를 할 필요 없으니 Non-Blocking 동기화라고도 한다.

Lock-Free 라고도 한다.

논블로킹 동기화의 하드웨어 지원

중요한 것은 1번 작업 실행과 2번 충돌 감지는 원자적으로 일어나야 한다는 것이다. 따라서 이는 하드웨어 명령어 지원이 필요하다.

현대의 프로세서들이 지원하는 논블로킹 동기화 명령어는 다음 것들이 있다.

• TAS(Test-and-Set
• FAA(Fetch-and-Add)
• Swap
• CAS(Compare-and-Swap)
• LL/SC(Load-Linked/Store-Conditinal)

CAS

위 명령어 중 하나인 CAS 를 알아보자. 이는 자바에서 지원하는 논블로킹 동기화다.

공유 자원 변수 X 에 대해

1. X 의 기존값이라고 예상하는 A
2. X 값으로 세팅할 B
3. 메모리 주소

세가지를 CAS 연산의 인자로 넣는다. 만약 실제 값이 A 와 같다면 B 로 값을 변경한다. 또한 이 작업은 하드웨어의 도움을 받아 원자적으로 일어난다.

자바의 CAS

• java.util.concurrent.AtomicInteger 외 Atomic 시리즈는 CAS 를 이용하여 원자적으로 연산하는 숫자를 만들 수 있다.
• JDK 9 부터 제공되는 VarHandle 을 사용하면 직접 CAS 를 사용할 수 있다.

Unsafe 의 cas 연산은 유저 사용 용도가 아니니 사용하지 말자. VarHandle 쓰자.

CAS 의 문제

대표적인 CAS 의 문제는 ABA 문제가 있다.

예상하는 값 A 가 맞다는건 X 를 읽어온 뒤 변경되지 않았다고 판단하는 것이다. 하지만 A 가 B 로 바뀌었다가 다시 A 로 돌아온 경우 CAS 는 변경되지 않았다고 판단할 수 있다.

java.util.concurrent.atomic 의 AtomicStampedReference 는 변수값의 버전을 관리하며 ABA 를 보완한다.

하지만 대부분 ABA 문제는 동시성 해결에 별로 중요치 않다. ABA 가 중요하다면 기존의 상호 배제 동기화를 고려해볼 수 있을 것이다.

동기화가 필요없는 메커니즘

다음 두가지는 동기화 자체가 필요 없는 안전한 메커니즘이다.

1. 재진입 가능한 코드 : 전역 변수, 힙 데이터, 공유 시스템 자원을 전혀 사용하지 않고 항상 같은 입력에 같은 출력을 반환하는 재진입 가능 코드는 스레드 안전하다.

2. 스레드 로컬 저장소 : 코드 조각에서 사용하는 데이터를 다른 코드와 공유해야하지만, 두 코드조각이 같은 스레드에서 동작함 이 보장되면 스레드 로컬 저장소를 사용할 수 있다. 스레드 로컬 저장소는 하나의 스레드만이 접근하기 때문에, 스레드 안전하다.

   • 자바에서는 ThreadLocal
   • 웹 서버에는 인증정보나 파라미터 등 요청당 정보들을 공유 변수가 아닌 스레드 로컬을 사용하여 동기화 문제를 피한다.

락 최적화

스핀락, 적응형 스핀락

• 컨텍스트 스위칭은 커널 스레드 정지 비용이 너무 높다. 하지만 대부분 락은 금방 끝난다.
• 커널 모드로 전환하여 커널 스레드를 정지하지 않고 않고 while 루프를 돌려서 기다린다.
• 다만 프로세서를 계속 사용한다는 단점 때문에, 일정 횟수 스핀 후 원래처럼 커널 스레드 대기한다.
• 적응형 스핀락 : 자바는 스핀 횟수를 적응형으로 그때그때 바꾼다.
  • 스핀락 시점에서 락 획득에 성공한다면 다음 번에는 횟수 이내에 락을 획득하지 못하더라도 스핀 횟수를 늘려 조금 더 기다려본다.
  • 만약 충분히 늘린 스핀에서도 계속해서 실패한다면 오래 걸리는 락이라 판단하여 아예 스핀락을 없앨수도 있다.

락 제거

• JIT 컴파일러의 최적화이다.
• 탈출 분석시 메서드의 힙 변수가 메서드를 탈출하지 않고 다른 스레드가 사용하지 않는다고 분석되면 스택 변수처럼 취급할 수 있다. -> 동기화도 제거할 수 있다.

탈출 분석은 비싼 분석이다. 프로시저간 분석을 해야 하기 때문이다. 개발자라면 꼭 필요한 부분에 락을 추가했을텐데, 이를 제거하기 위해 분석 하는것은 너무 비효율적이지 않을까?

그 이유는 우리 코드가 아닌 자바 API 들 때문이다. 자바는 보수적으로 작성한 동시성 코드가 상당히 많다. 필요하지 않다면 이 코드들을 없애는 최적화가 주 목적이다.

예를 들어 다음 코드를 보자

public class Test {

    public static void main(String[] args) {
        System.out.println(test("a", "b", "c"));
    }

    static String test(String s1, String s2, String s3) {
        return s1 + s2 + s3;
    }
}

위의 문자열 합치기는 JDK 1.4 까지는 javac 컴파일 타임에 StringBuffer 를 사용하는 코드로 바뀐다.

StringBuffer::append() 는 기본적으로 synchronized 블록이다. 하지만 JIT 는 위 코드를 실행할 때에는 필요없는 동기화 블럭을 제거한다. 물론 인터프리터 시점에는 락이 걸리겠지만 말이다.

참고로 String 더하기 연산은 JDK 5 부터 StringBuffer 가 아닌 StringBuilder 로 바뀐다. 다음은 JDK 8 로 컴파일한 클래스 파일

 0: new           #8                  // class java/lang/StringBuilder
 3: dup
 4: invokespecial #9                  // Method java/lang/StringBuilder."<init>":()V
 7: aload_0
 8: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
11: aload_1
12: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
15: aload_2
16: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
19: invokevirtual #11                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;

또한 JDK 9 부터는 invokedynamic 을 활용한다. 다음은 JDK 11 로 컴파일한 클래스 파일

3: invokedynamic #8,  0              // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;

락 범위 확장

이 또한 최적화의 한 종류로, 크게 락 한번 잡을 수 있는데 자잘하게 여러번 잡은 것들을 자동으로 큰 동기화 구문으로 바꿔준다.

경합이 없는 상황에서 불필요하게 상호 베제 동기화가 발생하는것을 막는 것이다.

예를 들어 StringBuffer 의 append() 를 연달아 쓰면 synchronized 블럭이 연속으로 몇번 왔다갔다 한다. 이를 큰 synchronized 블록 하나로 바꾸면 성능이 좋아질 것이다.

경량 락

일반적으로 지금까지 설명한 뮤텍스를 사용하는 락들은 모두 중량 락이다.

경량 락이란 중량 락보다 성능저하가 덜한 가벼운 락 메커니즘이다. 이는 대부분의 락은 경합을 하지 않음을 전제로, CAS 연산으로 동작한다. 따라서 경합이 없을때 동작하는 락이다.(아래 설명)

자바는 상호 배제 동기화를 하면 먼저 경량 락으로 객체를 동기화하고, 필요시에 중량 락으로 변경하여 동작한다.

경량 락의 동작

경량 락은 객체 레이아웃의 마크 워드 부분을 이용한다. 객체 레이아웃은 이 글 을 참고하자.

1. 락을 획득하기전 첫 상태. 공유 객체의 마크워드 플래그는 01 이다.

2. 락 획득을 시도하기 전 공유 객체의 마크 워드를 스택 프레임으로 복사한다.

   • 3번 단계에서 공유 객체의 마크 워드를 경량 락 동작을 위해 다른 정보로 대체하기 때문에 백업하는 용도.

3. 락을 획득하고자 하는 스레드는 공유 객체의 마크 워드를 자신의 스택 프레임 주소로 변경을 CAS 로 시도한다. 성공한다면 락을 획득 한 것이고, 실패한다면 다른 스레드가 이미 락을 잡은 것이다.

4. 만약 스레드가 공유 객체를 사용하는데 플래그가 00 이며(경량 락 상태), 스택 포인터 값이 본인의 스택 프레임이라면 자신이 락을 가지고 있음을 알 수 있다.

중량 락 변경

둘 이상의 스레드가 같은 락을 두고 경합하는 상황이라면 경량 락은 더 이상 유효하지 않다.

위 과정의 3번에서 락 획득에 실패했다면 중량 락으로 변경한다. 경합이 있는 과정에서는 CAS 연산 + 뮤택스 까지 둘 다 하게 되어 오히려 느려지기 때문에 중량 락으로 변경하는게 좋기 때문이다.

이 때 플래그는 중량 락을 가리키는 10 로 변경되며 중량 락으로 동작한다.

편향 락

편향 락은 경량 락에 한단계 더 가벼운 락이다. 편향 락을 획득한 스레드는 다른 스레드가 락을 획득하려 하기 전까진 CAS 연산 조차 없이 락을 획득할 수 있다.

마찬가지로 마크 워드를 사용하며 01 플래그를 사용한다.

https://wiki.openjdk.org/spaces/HotSpot/pages/11829266/Synchronization

하지만 최근 도입된 동시성 API 를 사용하면 불필요한 경합이 많이 줄어듦에 비해 편향락은 복잡한 작업을 거쳐야 하는 비용이 큰 락이라 최근 JDK 에서 삭제되었다.

1:1

• OS 가 제공하는 커널 스레드(커널의 복제본) 한개를 고수준 인터페이스인 경량 프로세스(스레드) 하나로 맵핑하여 사용

• 커널의 도움으로 경량 프로세스 각각이 독립적으로 스케줄링 된다. 따라서 경량 스레드 하나가 시스템 호출에서 블록되더라도 전체 프로세스는 영향을 받지 않는다.

• 커널 스레드를 기반으로 구현되었기에 생성, 소멸, 동기화 등 다양한 스레드 연산이 시스템 호출로 이뤄진다. 시스템 호출은 사용자 모드와 커널 모드의 전환이 발생하여 비용이 높다.

• 경량 프로세스 하나가 커널 스레드 하나를 사용하기에 경량 프로세스의 수에 제한이 있다.

  1:N

  

• 넓은 의미에서 1:1 의 경량 프로세스 또한 유저 스레드이지만, 좁은 의미에서는 온전히 사용자 공간에서 구현되는 스레드 라이브러리를 사용자 스레드라 한다. 1:N 관계에서는 좁은 의미의 사용자 스레드를 만들어 사용한다.

• 커널 모드로 전환할 필요가 없다.(고성능)

• 유저 스레드는 시스템 커널의 지원이 필요없다. 반대로 말하면 스레드의 생성, 소멸, 동기화, 스케줄링을 사용자 프로그램이 모두 처리해야 한다. 따라서 매우 복잡하고 어렵다.

• 어려운 난이도에 잘 사용하지 않는 모델이지만, go 와 Erlang 에서 사용하고 있다.

  N:M

  

• 사용자 스레드와 경량 프로세스 모두 사용한다.

• 스레드 스케줄링, 프로세서 매핑등의 OS 기능을 사용할 수 있으면서 사용자 프로그램에서 스레드 생성, 소멸, 스케줄링 비용을 저렴하게 구현하여 감당할 수 있는 동시성 규모가 커진다.

• 사용자 스레드의 시스템 호출은 온전히 경량 프로세스에 의해 수행되므로 프로세스 전체가 완전히 블록될 위험이 크게 줄어든다.

자바 스레드

JVM 은 따로 스레드 모델을 규정하진 않는다. 스레드 모델은 플랫폼 독립적으로 구현하려면 1:N 유저 스레드 모델을 사용해야 하는데 이는 1.2 까지 쓰이다 폐기되었다. 대부분은 OS 의 기본 스레드 모델인 1:1을 따른다. 따라서 JVM 은 스레드 스케줄링 등을 관리하지 않고 OS 에 맡긴다.

자바 스레드 스케줄링

자바는 기본적으로 선점형 스케줄링을 사용한다. 코틀린 코루틴을 사용하면 JVM 에서도 협력적 스케줄링을 사용할 수 있다.

협력적 스케줄링

• 스레드 실행 시간을 스레드 스스로 결정. 스레드는 작업을 마치면 시스템에 알림.
• 장점
  • 구현이 쉽다
  • 동기화 문제 발생 확률이 적다. 멈출 시점을 명확하게(코드로 지정) 알고 있기 때문이다.
    • 반면 선점형 스케줄링은 스레드가 언제 멈출지 모른다. 임계 영역에서 멈추면 동시성에 문제가 생기기 쉽다.
• 단점
  • 스레드 실행 시간을 제어할 수 없다. 스레드가 문제가 있어 블럭되면 제어를 프로그램에 돌려주지 못해 프로그램 자체가 멈춘다.

    선점형 스케줄링

• 각 스레드의 실행 시간을 시스템이 할당
• 스레드들은 전환 시점을 자신이 결정하지 못함. Thread::yield() 는 능동적으로 제어권을 포기하지만 제어권을 가져오는 방법은 없다.
• 장점
  • 시스템이 실행 시간을 결정하기에, 문제가 발생한 스레드를 강제로 멈출 수 있다. 프로그램 전체가 멈추는 사태는 없다.

윈도우의 경우 과거 협력적 스케줄링 방식으로 프로세스 하나가 문제가 생기면 전체가 먹통이 되었다. 현재는 선점형 스케줄링 방식을 사용하므로 작업관리자로 특정 프로세스 하나를 종료할 수 있다.

자바 스케줄링 우선순위

자바 스레드는 제어권을 가져올 순 없지만, 스레드별로 우선순위를 가지고 시스템에게 권고할 수 있다.

Thread.MIN_PRIORITY(1) ~ Thread.NORM_PRIORITY(5) ~ Thread.MAX_PRIORITY(10) 의 10가지다.

하지만 이는 단순 권고이지 그대로 믿으면 안된다.

특히 자바 스레드 우선순위는 OS 스레드 우선순위와 연결되어야 하는데, 윈도우는 스레드 우선순위가 7가지다. 따라서 자바 스레드 우선순위는 윈도우 스레드 우선순위로 연결되면서 문제가 생긴다. 자바 우선순위 1, 2 는 THREAD_PRIORITY_LOWEST 하나로 연결되어 자바에는 1, 2 로 구분했지만 윈도우에서는 같은 우선순위를 가지는 일이 생긴다. 마찬가지로 3과 4,6과 7, 8과 9가 그렇다.

스레드 상태 전이

자바의 스레드는 항상 위 6가지 하나의 상태를 가진다.

Waiting

• Object::wait(인자없음)
• Thread::join(인자없음)
• LockSupport:park()

Timed Waiting

• Thread::sleep()
• Object::wait(시간)
• Thread::join(시간)
• LockSupport::parkNanos()
• LockSupport::parkUntil()

Blocked 와 Waiting Waiting 은 스레드가 잠들어 누군가가 깨워야 한다. 반면 Blocked 는 락을 얻기 위해 기다리는 상태이며, 락을 얻으면 Running 으로 바뀐다.

가상 스레드

자바는 커널 스레드와 자바 스레드를 1:1 맵핑한다. 자바 스레드는 커널 스레드의 자세한 기능을 숨기는 인터페이스를 제공하여 자바 애플리케이션 개발을 쉽게 할 수 있었다. 자바 서블릿은 하나의 커널 스레드에 하나의 Http 요청을 맵핑할 수 있었다.

하지만 컴퓨터가 빨라지고, 요청이 많아지고, MSA 환경에서 IO 가 많아지면서 1:1 모델의 단점인 자원의 한계가 두드러졌다. 짧고 많은 요청은 요청 시간과 컨텍스트 스위칭 시간이 거의 비슷해지는 지경에 이르렀다.

컨텍스트 스위칭 비용

1. 스레드 전환시 문맥 저장 비용(캐시, 메모리, 레지스터 쓰기)
2. 스레드 복원시 문맥 복원

컨텍스트 스위칭 비용이 상대적으로 커졌다.

코루틴

스레드 전환시 문맥에 대한 저장/복원이 비용이라 한다면, 이를 애플리케이션에서 처리하면 된다.

커널에서 컨텍스트 스위칭을 위한 비용보다 애플리케이션 스택에서 처리하는게 더 빠르고 좋다. 즉, 스레드 스케줄링을 각 코루틴이 하는 것이다.

1. 커널 모드로 들어가지 않아도 된다.
2. 공간 자체도 적게 든다.

하지만 코루틴은 협력적 스케줄링 방식으로서 애플리케이션에서 OS 가 하던 기능을 모두 구현하기는 매우 어렵다.

코루틴 <> 협력적 스케줄링 <> 사용자 스레드 <> 가상 스레드 넷은 비슷비슷한 말이다.

스택풀 코루틴 : 코루틴이 각각 스택에 문맥을 위한 저장을 한다. 스택리스 코루틴 : 스택이 없고 상태 머신으로 스레드를 복구한다.

협력적 스케줄링을 사용하는 코루틴이 보통의 개념이다. 하지만 비협력적 스케줄링을 사용하는 코루틴도 있다.

가상 스레드

https://waterfogsw.tistory.com/72

Loom 프로젝트로 불리던 Java 가상 스레드는 일종의 코루틴이다. 자바가 복잡한 코루틴을 구현 해 준 것이다. JDK21 에 정식 반영되었으며, 기존의 Thread 에 추가된 기능이기에 코드 변경이 적다.

가상 스레드의 애플리케이션 레벨 스케줄러는 기본적으로 ForkJoinPool 을 사용한다.

하드웨어에서의 동시성

CPU 의 프로세스는 매우 빠르다. 그에 비해 메모리에 값을 저장하고 읽는 속도는 느리다. 이 CPU 와 메모리의 처리속도를 보완하기 위해서, 읽고 쓰는 중간에 캐시 레이어를 둔다. 그러면 위와 같은 그림의 구조가 되는데, 이를 공유 메모리 멀티 프로세스 시스템 이라 한다.

하지만 캐시 구조는 동시성 문제를 유발하기 때문에, 캐시들 사이의 값을 일치시키기 위해 캐시 일관성 프로토콜 을 사용한다. 이는 캐시 일관성 프로토콜은 여러 캐시에서 읽고 수정되는 값이 일관성 있도록 처리한다.

또한 캐시에는 store buffer 라는 놈이 존재하는데, CPU 는 결과가 같다면 버퍼에 저장된 명령어의 순서를 변경할 수 있다. 이는 일부 시나리오에서 동시성 문제를 발생시킬 수 있다.

자바 메모리 모델

메모리 모델 은 특정 프로토콜을 통해 메모리나 캐시를 읽고 쓰는 절차

자바 메모리 모델의 목적은 자바 프로그램에서 변수에 접근하는 규칙을 정함으로써 여러 스레드가 메모리에 접근해도 동시성 문제가 발생하지 않도록 하는 것이다.

메인 메모리, 작업 메모리

JVM 은 가상 머신으로 하드웨어와 비슷한 공유 메모리 멀티 프로세스 시스템을 가진다. 위 그림의 작업 메모리, 메인 메모리의 역할은 하드웨어와 비슷하다. 단, 이 메모리는 하드웨어처럼 물리 메모리를 나타내는게 아닌 JVM 개념 상의 메모리를 말한다.

실제로 구현 상 작업 메모리 저장소를 CPU 캐시나 레지스터로 구현하기도 한다. 자주 이용하고 빨라야하기 때문이다.

위 그림에서 작업 메모리와 메인 메모리 사이에 값을 주고 받는 프로토콜로 저장, 읽기 라고 나와있다. 이 부분이 Java Memory Model 이다. JVM 상에서 스레드, 작업 메모리, 메인 메모리간 변수를 읽고 쓰는 동작을 정의한다.

JVM 은 여러 하드웨어 플랫폼에서 동작해야하기 때문에 Java Memeory Model(JMM) 은 추상적으로 작성된 규칙이다. 이 덕분에 자바 프로그램은 어느 운영체제 및 메모리 모델에 상관없이 일관성 있게 메모리를 사용할 수 있다.

JMM 연산

메인 메모리와 작업 메모리 사이의 프로토콜, 즉 메인 메모리에서 작업 메모리로 값을 복사하고 작업 메모리의 값을 메인 메모리로 동기화하는 방법을 JVM 은 다음 8가지로 정의했다.

이 8가지 연산을 원자적 으로 제공해야 한다.

JMM 연산 규칙

위 8가지 연산을 실행할때에는 몇가지 규칙을 지켜야한다. 어떠한 프로그램의 동시성 안전을 체크하고 싶을 때 규칙들을 적용하면 확인이 가능하다.

추가로 잠금 관련해서는,

• 변수는 한번에 한 스레드만 잠글 수 있다. 같은 스레드라면 n번 잠글 수 있으며, 잠금 해제를 위해 n번 해제해야 한다.
• 변수를 잠그면 작업 메모리의 변숫값은 지워진다. 변수를 사용할 때 적재 또는 할당을 다시 실행하여 작업 메모리에 값을 다시 초기화 해야 한다.
• 잠근 스레드만 잠금을 해제할 수 있다.
• 잠금을 해제하려면 작업 메모리 값을 메인 메모리에 동기화 해야 한다.(저장/쓰기)
• volatile 관련 규칙. (happens-before)
  • 작업 메모리에서 volatile 변수가 사용될 때 마다 다른 스레드에서의 변경 사항을 볼 수 있도록 메인 메모리로부터 값을 최신 값으로 고쳐야 한다.
  • 작업 메모리에서 volatile 변수가 수정될 때 마다 메인 메모리로 즉시 동기화되어 다른 스레드가 변경 사항을 볼 수 있도록 보장해야 한다.
  • 재정렬을 막아 프로그램에서 정의한 순서대로 실행해야 한다.
• long, double 은 64 비트 데이터타입으로, 32비트 시스템에서는 이 데이터 타입에 대한 모든 연산이 비원자적일 수 있기 때문에 보장해야 한다. 현재는 대부분의 CPU 레벨에서 이를 지원하므로 신경쓰지 않아도 된다.

Volatile

동시성에는 가시성과 원자성이라는 단위가 있다. synchronized 키워드는 가시성과 원자성을 모두 만족시키지만 비용이 비싸다. 때로는 가시성만 필요할때가 있는데, 이 때 사용하는 것이 volatile 이다.

가시성

가시성은 공유 변수의 값을 한 스레드가 수정했다면 다른 스레드가 즉시 수정을 알 수 있느냐이다.

가시성이 깨질 수 있는 케이스는 두가지이며, 하드웨어와 가상머신 모두에서 발생할 수 있다.

1. 공유 메모리 멀티 프로세스 시스템 : 캐시, 작업 메모리에 저장한 값이 메인 메모리로 동기화 되기 전 다른 스레드/프로세스가 읽어간 경우 가시성이 깨질 수 있다.
2. 명령어 재정렬 : JVM, CPU 는 결과가 같은 경우에 한해 최적화의 일환으로 명령어의 순서를 변경할 수 있다. 하지만 명령어 순서 변경에 의해 다른 스레드에서 값을 잘못 읽어가는 가시성 문제가 생길 수 있다.

JVM 가시성 문제

위처럼 가시성이 깨지는 경우 때문에, 일부 시스템은 캐시 또는 작업 메모리 개념을 사용하지 않거나 명령어 재정렬을 허용하지 않을 수 있다.

하지만 JVM 은 성능상의 이점을 위해 작업 메모리를 사용하고, JIT 의 명령어 재정렬을 허용한다.

즉, 특정 시나리오의 경우 가시성 문제가 발생할 수 있으며 Volatile 키워드를 일일히 붙여야 함을 택했다.

Java Volatile

volatile 은 위 가시성 문제를 해결하기 위한 방법이다. volatile 은 두가지 기능이 있다.

1. 모든 스레드에서 변수값을 투명하게 볼 수 있다. 이를 위해 캐시, 작업 메모리 값을 무효화해야 한다.
2. 명령어 재정렬 최적화를 막는다. (happens-before 관계 성립)

가시성 문제는 가상머신(인터프리터, JIT), 하드웨어(CPU) 둘 다 발생할 수 있다고 했다. JVM 은 여러 하드웨어의 추상화 가상 머신이다. 따라서, volatile 은 JVM 과 CPU 둘다의 가시성 만족 을 위한 구현이다.

즉, volatile 은 작업 메모리와 cpu 캐시 둘 다를 무효화 시키며, JIT 의 명령어 재정렬과 CPU 의 명령어 재정렬 둘 다를 막는다.

가상머신 레벨의 volatile

volatile 변수는 클래스 파일에서 필드 테이블에 ACC_VOLATILE 플래그 정보가 있다.

가상머신은 이 플래그가 켜져 있으면(volatile) 위 volatile 관련 규칙을 지켜야 한다. 모든 JVM 은 이 규칙을 지키도록 되어 있다.

하드웨어 레벨의 volatile

가상머신 레벨의 volatile 구현은 jvm 하나만 잘 구현되어 있으면 된다. 하지만 하드웨어는 다르다.

x86, amd, arm 등등 여러 CPU 는 각각 다른 가시성 구현을 가지고 있다. 따라서 JVM 은 volatile 변수 명령에 대한 네이티브 코드 생성시 CPU 에 따라 다르게 만들어야 한다.

따라서 volatile 이 실제로 cpu 레벨의 가시성 제어는 어떻게 되는지 알고싶다면, CPU 까지 알아야 한다.

JDK 동시성에 큰 기여를 한 Doung Lea 의 자료를 참고하면 좋다. https://gee.cs.oswego.edu/dl/jmm/cookbook.html

매모리 재정렬을 막는 경계를 설정하는 명령을 barrier 라 한다. 베리어에는 LoadLoad, LoadStore, StoreLoad, StoreStore 네종류로 나눌 수 있으며 StoreLoad 베리어는 Store 명령과 Load 명령 사이에 들어가는 베리어 명령어로써 Store 명령어는 베리어를 넘어서 재정렬될 수 없다는 식이다.

X86

x86 CPU 는 CPU 단에서 대부분의 재정렬을 이미 막고 있다. (TSO, Total Store Order) 따라서 StoreLoad 재정렬만 막으면 된다.

다음 코드를 JIT 컴파일러는 어떤 네이티브로 해석하는지 보자 instance 변수를 volatile 로 하고 안하고를 비교해보겠다.

// double-checked-locking 코드. 대표적인 volatile 사용처
public class Singleton {
//    private static Singleton instance;
    private volatile static Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    static void main(String[] args) {
        Singleton s = Singleton.getInstance();
        System.out.println(s);
    }
}

윈도우에서 hsdis 사용하여 테스트함.

  0x000001c53532bc1f:   movsbl 0x38(%r15),%edi
  0x000001c53532bc24:   cmp    $0x0,%edi
  0x000001c53532bc27:   jne    0x000001c53532bd82
  0x000001c53532bc2d:   mov    %rax,%r10
  0x000001c53532bc30:   shr    $0x3,%r10
  0x000001c53532bc34:   mov    %r10d,0x70(%rsi)
  0x000001c53532bc38:   mov    %rsi,%rdi
  0x000001c53532bc3b:   xor    %rax,%rdi
  0x000001c53532bc3e:   shr    $0x15,%rdi
  0x000001c53532bc42:   cmp    $0x0,%rdi
  0x000001c53532bc46:   jne    0x000001c53532bda1           ;*putstatic instance {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Singleton2::getInstance@24 (line 9)

위는 volatile 이 아닐때의 일부다.

  0x000001f7c9fb3f1f:   movsbl 0x38(%r15),%edi
  0x000001f7c9fb3f24:   cmp    $0x0,%edi
  0x000001f7c9fb3f27:   jne    0x000001f7c9fb4088
  0x000001f7c9fb3f2d:   mov    %rax,%r10
  0x000001f7c9fb3f30:   shr    $0x3,%r10
  0x000001f7c9fb3f34:   mov    %r10d,0x70(%rsi)
  0x000001f7c9fb3f38:   lock addl $0x0,-0x40(%rsp) // 추가됨
  0x000001f7c9fb3f3e:   mov    %rsi,%rdi
  0x000001f7c9fb3f41:   xor    %rax,%rdi
  0x000001f7c9fb3f44:   shr    $0x15,%rdi
  0x000001f7c9fb3f48:   cmp    $0x0,%rdi
  0x000001f7c9fb3f4c:   jne    0x000001f7c9fb40a7           ;*putstatic instance {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Singleton::getInstance@24 (line 9)

위는 volatile 일때의 일부다.

보다시피 volatile 일 때에는 lock addl $0x0,-0x40(%rsp) 네이티브 명령이 변수값 할당 후 추가된다.

lock 접두어는 IA32 메뉴얼상 캐시(정확하게는 store buffer)를 메인 메모리에 쓰는 기능을 하며 이 쓰기는 다른 프로세서가 자신의 캐시를 무효화하게 한다.

이 명령어가 끝나기 전에 캐시의 값을 메모리에 모두 쓰는 것을 보장하므로, 다른 스레드에서는 변수의 수정된 값을 투명하게 볼 수 있다. (과거 값을 보는게 불가능하다)

또한 의미상 lock 은 캐시에 들어있는 이전의 쓰기 연산을 모두 메모리에 반영 함으로서 관측 가능하게 한다는 의미이기 때문에, 이를 재정렬해버리면 다른 스레드에서의 관측 결과를 달라지게 할 수 있다. 따라서 lock 이 캐시의 명령을 모두 메모리에 동기화하는 것이 명령어 재정렬은 lock(베리어) 를 넘을 수 없다는 효과 또한 발생시키게 된다.

lock 명령 하나로 두마리 토끼를 잡을 수 있는 것이다.

뒤의 addl $0x0,-0x40(%rsp) 는 별 의미 없는 코드다. 필요한건 lock 뿐이다. 다만 lock 이 쓰기 연산에만 붙을 수 있는 접두어라 한다.

cpu 는 의미(sementic) 이 바뀌지 않는 내에서 재정렬할 수 있다.

arm

arm 에서 위 코드를 실행해보면 dmb(Data Memory Barrier) 가 추가됨을 알 수 있다.

  0x000000010e0caf3c:   cbnz    x0, 0x000000010e0cb164      ;*monitorenter {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Singleton::getInstance@10 (line 7)
  0x000000010e0caf40:   mov    x3, #0x8ea0                    // #36512
                                                            ;   {oop(a 'java/lang/Class'{0x000000043f818ea0} = 'Singleton')}
  0x000000010e0caf44:   movk    x3, #0x3f81, lsl #16
  0x000000010e0caf48:   movk    x3, #0x4, lsl #32
  0x000000010e0caf4c:   ldr    w3, [x3, #112]
  0x000000010e0caf50:   lsl    x3, x3, #3                  ;*getstatic instance {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Singleton::getInstance@11 (line 8)

위는 volatile 없을 때

  0x000000010ee8af44:   cbnz    x0, 0x000000010ee8b184      ;*monitorenter {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Singleton::getInstance@10 (line 7)
  0x000000010ee8af48:   mov    x3, #0x8ea0                    // #36512
                                                            ;   {oop(a 'java/lang/Class'{0x000000043f818ea0} = 'Singleton')}
  0x000000010ee8af4c:   movk    x3, #0x3f81, lsl #16
  0x000000010ee8af50:   movk    x3, #0x4, lsl #32
  0x000000010ee8af54:   dmb    ish
  0x000000010ee8af58:   ldr    w3, [x3, #112]
  0x000000010ee8af5c:   lsl    x3, x3, #3
  0x000000010ee8af60:   dmb    ishld                       ;*getstatic instance {reexecute=0 rethrow=0 return_oop=0}
                                                            ; - Singleton::getInstance@11 (line 8)

위는 volatile 있을 때

volatile 은 원자성을 만족시키지 않는다.

public volatile int count = 0;

public add() {
    count++;
}

위 add() 메서드는 volatile 변수를 증가시키는게 다이다. 하지만 이 메서드는 동시성 안전하지 않다.

volatile 은 원자성을 만족시키지 않기 때문이다.

count++ 는 실제로 하나의 명령어가 아니라 여러개의 바이트 코드, 더 여러개의 네이티브 코드로 쪼개진다.

cpu 는 이 여러개의 명령어를 원자적으로 실행하지 않으므로 동시성 문제가 발생할 수 있다.

따라서 volatile 은 사용처를 잘 보고 사용해야 한다.

volatile 을 언제 써야 하는가?

기본적으로 volatile 이 synchronized 보다 성능이 좋다.

volatile 은 아래 두 조건이 모두 만족해야 한다. 아닐때에는 synchronized 를 쓰도록 한다.

• write 할 값이 write 이전 값과 관계가 없다. (싱글 스레드 동작이 보장된다면 상관없음)
  • 기존 값을 읽어서 기존 값 기반으로 바뀐 값을 write 하면 안된다는 이야기다.
• 다른 상태 변수와 관련한 불변성 제약 조건에 관여하지 않는다.

두번째 조건은 다음 예와 같다. 원자적이지 않으므로 다른 변수와의 불변성 제약조건이 깨질 위험이 있다.

volatile int lower;
volatile int upper;

// 메서드가 원자성이 없으므로 (5, 5) -> (10, 10) 으로 변경시 (10, 5) 시점에 읽으면 예외가 날 수 있다.
void set(int l, int u) {
   lower = l;
   upper = u;
}

void check() {
   if (l > u) throw new Exception(); // 불변성 제약조건
}

대표적인 사용처는 flag 값으로 쓰일때가 있다.

volatile boolean shoutdown;

public void shutdouwn() {
    this.shoutdown = true;
}

public void doWork() {
    while(!shutdown) {
        ...
    }
}

synchronized

synchronyzied 는 동기화 블록을 만든다. 이 블록은 가시성, 원자성을 모두 만족한다.

• 원자성 : monitorenter, monitorexeit 바이트 코드 명령어로 확보됨
• 가시성 : JMM 규칙 중 변수의 잠금을 해제하기 전 변수의 값을 메인 메모리로 다시 동기화해야 함 에 의해 확보됨

동시성의 3요소

1. 가시성 : volatile, synchronized 둘 다 만족
2. 원자성 : synchronized 만 만족
3. 실행 순서 : volatile, synchronized 둘 다 만족

선 발생 원칙

먼저 작성된 프로그램의 코드는 무조건 뒤에 작성된 코드에서 볼 수 있을까? 먼저 실행된 코드의 결과는 무조건 뒤에 실행된 코드에서 볼 수 있을까?

아니다. 먼저 실행 되더라도 재정렬 및 캐시 구조때문에 그렇지 않다.

B 가 수행되기 전에 A 에서 수행한 결과를 B 에서 관찰할 수 있다면 A 는 B 보다 선발생 했다고 한다. 실행이 아닌 수행임을 주의하자. 먼저 실행되더라도 나중에 수행되어 볼 수 없을 수 있다는 이야기다.

자바는 volatile, synchronized 를 쓰지 않더라도 기본적으로 보장해주는 것들이 있다. 동시성 문제를 분석할 때에는 이를 참고해야 한다.

1. 프로그램 순서 규칙 : 한 스레드 안에서는 제어 흐름(분기, 순환문 등등) 순서에 따라 앞의 연산이 뒤따르는 연산보다 선 발생한다. 코드 순서가 아니다.
2. 모니터 락 규칙 : 같은 락에 대한 시간적으로 먼저인 잠금 해제는 잠금 보다 선 발생한다.
3. 휘발성 변수 규칙 : volatile 시간적으로 먼저인 변수 쓰기는 같은 변수에 대한 읽기 연산보다 선 발생한다.
4. 스레드 시작 규칙 : Thread.start() 는 해당 스레드의 어떤 작업보다 선 발생한다.
5. 스레드 종료 규칙 : 스레드의 모든 작업은 스레드 종료보다 먼저 발생한다.
6. 스레드 인터럽트 규칙 : Thread.interrupt() 호출은 인터럽트되는 스레드의 인터럽트 이벤트 발생 감지보다 선 발생한다.
7. 종료자 규칙 : 객체 초기화(생성자)는 finalize() 시작보다 선 발생한다.
8. 전이성 : A 보다 B 가 선 발생하고, B 보다 C 가 선 발생하면 A 보다 C 가 선 발생한다.

모니터 락 규칙 // Thread A synchronized (lock) { x = 42; } // unlock // Thread B synchronized (lock) { System.out.println(x); }

라면 B 의 출력은 반드시 42 이다. 이 보장이 없다면 이전 값을 출력할 수 있다. synchronized 를 보장하는 규칙이라할 수 있다.

무조건 시간상 먼저 발생하는 작업이 선 작업을 의미하지 않는다는 것이다. 그걸 만족하는건 위 케이스밖에 없다.

참고

https://gee.cs.oswego.edu/dl/jmm/cookbook.html https://chriswhocodes.com/hsdis/ 논문 A Volatile-by-Default JVM for Server Applications

https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html https://www.cs.umd.edu/users/pugh/java/memoryModel/

https://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html https://velog.io/@hmcck27/Double-Checked-Locking

논문 Specifying Multithreaded Java Semantics for Program Verification

jaotc

Jaotc 는 JDK 9 ~ JDK 16 에 포함된 JDK AOT 컴파일러이다. JEP 295 에서 제안되었으며 JEP 410 에서 사라졌다.

jaotc --output jaotcResult.so jaotcSource.class

와 같이 미리 AOT 컴파일러로 so 파일을 만들고,

java -XX:+UnlockExperimentalVMOptions -XX:AOTLibrary=./jaotcResult.so HelloWorld.class

와 같이 실행할 수 있다.

하지만 JEP 295 에도 적혀 있듯, 아무도 쓰지도 않고 사용 자체도 어려워서 JDK 에서 빠지게 되었다. 그래서 굳이 jaotc 를 공부할 필요는 없다.

대신 jaotc 는 내부적으로 Graal Compiler 를 사용했으며, jaotc 는 JDK 16 에서 빠지고 난 후 Graal 프로젝트로 편입되었다.

따라서 이제는 GraalVM 을 알아봐야 한다.

GraalVM

Graal VM 은 다음과 같은 기능들을 내걸고 있다.

• Graal Compiler 를 사용하여 바로 실행 가능한 Native-Image 생성(AOT)
• 일반 JVM 의 C2 대신 Graal Compiler 사용 가능
• 고성능 및 메모리 사용량 감소 컴파일러
• Polyglot(ex. 자바에서 JS 코드 사용 가능)

이러한 기능들이 가능한 근본은 Graal Compiler 때문이다.

GraalVM

GraalVM 은 HotSpot 을 기반으로 만들어진 일종의 JVM 이다. C2 컴파일러 대신 Graal Compiler 가 동작한다.

GraalVM 은 HotSpot 처럼 일반적인 java 파일을 실행할 수 있으며, Native Image 생성시에도 사용될 수 있다.

Graal Compiler

그랄 컴파일러는 처음에는 HotSpot 의 C2 를 대체하기 위한 컴파일러였다. 여기에 다른 몇가지 요구사항들이 합쳐지면서 위의 기능을 모두 제공해주는 GraalVM 의 근본이 되었다.

몇가지 중요한 특징을 알아보자

1. 자바로 작성된 컴파일러다

C++ 로 짜여진 C2 컴파일러에 반해, 그랄 컴파일러는 JEP-243 의 JVMCI 덕분에 자바로 작성될 수 있었다.

• 자바 컴파일러 개발자들이 익숙한 언어로 개발을 더 쉽게 할 수 있다.
• 일반 개발자들이 컴파일러를 디버깅할 수 있다. (중단점 걸고 볼 수 있음)

2. 언어 독립적인 컴파일러다.

언어 독립성이란 말 그대로다. JS 를 GraalVM 에서 실행시킬 수 있다는 것이다. 하지만 중요한 것은 JS 의 특성 및 최적화는 적용되어야 한다.

Graal Compiler 개발진은 애초부터 여러 언어를 지원할 수 있는 컴파일러를 만들고 싶어 했다.

한편 생각해보면 JS 를 Java Class File 로 변환하는 컴파일러를 만들면 되지 않는가? 모든 언어를 Java Class File 로 만드는 컴파일러를 만들면 이미 C2 는 언어 독립적인 컴파일러 같기도 하다.

하지만 그렇지 않다. Java Class File 은 이미 스택 구조, 메서드 호출 규약(invokevirtual) 등 이미 자바에 맞춰진 파일이다. JS 를 Java Class File 로 바꾼다면 JS 의 동적인 특성은 모두 사라지고 없을 것이다.

그렇다면 어떻게 모든 언어를 대상으로한 독립성을 지킬 수 있을까. 모든 언어는 다르게 생겼지만 하고자 하는 것은 같다. 하드웨어를 동작시켜서 원하는 동작을 하기 위해 언어를 작성하는 것이다. 즉, 실행 흐름 은 모든 언어에서 같을 것이다.

Graal Compiler 는 실행 흐름을 컴파일한다. 실행 흐름을 나타내는 Graph 라는 Graal IR 을 네이티브 코드로 변환한다. 이 방식으로 언어의 독립성을 실현했다.

비교하자면 C2 Compiler 는 Java Class File 을 네이티브 코드로 컴파일하지만, Graal Compiler 는 Graph(Graal IR) 을 네이티브 코드로 컴파일한다.

3. native-image 생성에 사용된다.

4. 3번과 더불어, HotSpot 내부의 C2 대체 JIT 컴파일러로도 쓰일 수 있다.

• GraalVM 은 C2 대신에 그랄 컴파일러가 내장된 JVM 이다. 우리가 작성하던 왠만한 코드는 모두 실행할 수 있다.
• JDK 25 에서는 제거되었지만, 예를 들어 JDK 24 에서는 java 옵션으로도 C2 컴파일러 대신 Graal Compiler 를 사용할 수 있다.

GraalVM 설치

가장 먼저 GraalVM 을 설치해야 한다.

Mac 에서 가장 쉽게 GraalVM 을 사용하는 방법은 SDKMAN 을 사용하는 것이다.

https://www.graalvm.org/latest/getting-started/macos/#sdkman

Native Image 만들기

GraalVM 은 여러가지 방법으로 Native Image 를 만들 수 있다.

클래스, jar, java-module 을 gradle, maven, cli tool 을 사용하여 네이티브 이미지를 만들 수 있다.

이번에는 간단하게 native-image cli tool 을 써볼 예정이다. native-image cli tool 은 GraalVM 내부에서 제공하는 툴로써, GraalVM 과 내부의 Graal Compiler 를 사용하여 자바 코드를 Native Image 파일로 생성할 수 있다.

Polyglot 을 이용하면 타 언어도 가능

native image 에는 사전 컴파일된(AOT) 네이티브 코드와 해당 네이티브 코드를 JVM 없이 실행할 수 있는 런타임(Substrate VM) 이 포함되어 있다.

Native Image 특징

• 독립 실행 가능하다(SubStrate VM)
• 모든 코드를 분석하여 가상 메서드를 직접 호출 메서드로 만든다
  • 가상 메서드는 런타임에 리시버에 따라 호출할 메서드를 동적으로 디스패치 해야 하기 때문에 JIT 컴파일에서 섣불리 최적화(ex. inline)하지 못한다. 모든 코드를 분석하려면 시간이 많이 걸리고, 런타임에 이를 수행하기 부담스럽기 때문이다. 따라서 예측 기반 공격적 최적화를 할 수 밖에 없다.
    • 반면 AOT 방식인 Graal Native-Image 에서는 사전에 모든 코드를 분석하여 가상 메서드를 직접 호출 메서드로 바꾼다. 이는 JIT 는 할 수 없는 추가 최적화가 가능하도록 만든다.
• 런타임에 동작하는 몇몇 기능을 사용하지 못한다.
  • 리플랙션, Dynamic Proxy, Dynamic Class Loading, Runtime Annotation Processor 를 사용하지 못한다.
  • 따라서 Dynamic Class Loading 을 사용하는 Logback, 리플랙션을 사용하는 Jackson 등을 사용하지 못할 수 있다.
  • GraalVM 이 제공하는 Trace Agent 를 사용하여 해결해야 한다.

Native Image 실습

https://www.graalvm.org/latest/reference-manual/native-image/#from-a-class

1. java 파일 생성

   public class HelloWorld {
   public static void main(String[] args) {
    System.out.println("Hello, World!");
   }
   }

2. 컴파일 및 네이티브 이미지 생성

   javac HelloWorld.java
   native-image HelloWorld

   

3. 실행

   ./helloworld

   

Polyglot

https://giljae.medium.com/graalvm-%EC%86%8C%EA%B0%9C-84ac547f8df2 GraalVM 을 이용하면 JS 코드를 Java 에서 사용할 수 있다. 또는 JS 파일에 작성된 함수를 Java 에서 불러와 실행할 수 있다. JS 뿐만 아니라 C, C++, Ruby, Python 등등 많은 언어가 가능하다.

이를 Polyglot 이라 한다.

Truffle 은 언어를 만드는 프레임워크다. 언어를 만든다는건 사실 언어를 기계어로 바꾸는 인터프리터를 만드는 것이다.

Truffle 프레임워크로 만든 애플리케이션은 JS, Python, R 또는 커스텀한 언어를 AST 로 만드는 AST 인터프리터다. AST 는 원래 언어(JS, Python ..) 의 실행 흐름을 담고 있는 자바 객체 트리로서, JVM 에서 실행하면 원래 언어의 코드가 실행되는 것이다.

JS는 HotSpot JVM에서 실행된다. 다만 HotSpot이 JS를 직접 이해해서 실행하는 게 아니라, Truffle로 구현된 JS 인터프리터(자바 코드)를 실행함으로써 실행된다.

Truffle 프레임워크로 만들어진 인터프리터가 변환한 AST 는 자바 객체이기 때문에 GraalVM 이 아니더라도 HotSpot 에서도 실행될 수 있다.

하지만 Graal Compiler 를 만났을 때 가장 높은 수준의 최적화가 이뤄질 수 있다. 다음 표를 보자.

https://www.graalvm.org/latest/reference-manual/embed-languages/#runtime-optimization-support

Polyglot실습하기

1. gradle 프로젝트를 만들고 다음 의존성을 추가한다.

   // 우리 코드에서 사용할 polyglot api.
   // Truffle 프레임워크를 의존성으로 따라 가져온다.
   // Truffle 프레임워크는 정의된 언어 컨텍스트의 구현체로 요청을 디스패치하여 해석한 후 Graph 를 만든다
   implementation("org.graalvm.polyglot:polyglot:25.0.2")
   

// JS 폴리글랏 구현체. Truffle 에서 정의한 인터페이스에 맞게 구현되어 있으며, JS 문법을 Truffle 인터페이스로 바인딩한다고 볼 수 있다. // 예를 들면 JS 를 해석하여 Truffle 인터페이스 A 로 바인딩하는 식. implementation("org.graalvm.polyglot:js:25.0.2")

2-1. java 파일에서 js 코드 실행하기
```java
import org.graalvm.polyglot.Context;
import org.graalvm.polyglot.Value;

public class JsFunctionCallDemo {
    public static void main(String[] args) {
        try (Context ctx = Context.newBuilder("js").build()) {
            ctx.eval("js", """
                function add(a, b) { return a + b; }
            """); // js code

            Value bindings = ctx.getBindings("js");
            Value add = bindings.getMember("add");

            int res = add.execute(1, 2).asInt();
            System.out.println(res); // 3
        }
    }
}

2-2. java 에서 js 파일 읽어서 실행하기 js file

// Hello.js
// gradle 프로젝트 최상위에 위치시키기
function add(a, b) {
    return a + b;
}

java file

import org.graalvm.polyglot.Context;
import org.graalvm.polyglot.Source;
import org.graalvm.polyglot.Value;

import java.io.File;

public class JsFileCallDemo {
    public static void main(String[] args) throws Exception {
        File jsFile = new File("hello.js");

        try (Context ctx = Context.newBuilder("js").build()) {
            Source src = Source.newBuilder("js", jsFile).build();
            ctx.eval(src);

            Value bindings = ctx.getBindings("js");
            Value add = bindings.getMember("add");

            int res = add.execute(10, 32).asInt();
            System.out.println(res); // 42
        }
    }
}

https://www.graalvm.org/latest/reference-manual/native-image/guides/build-polyglot-native-executable/?utm_source=chatgpt.com

GraalVM 으로 공유 라이브러리 AOT 컴파일

https://www.graalvm.org/latest/reference-manual/native-image/guides/build-native-shared-library/

Galahad 프로젝트

Galahad 는 GraalVM 기술이 JDK 에 포함되도록 하는 프로젝트이다.

AOT Compiler

프로그램 실행(런타임) 이전에 최적화(C1, C2) 와 네이티브 코드 생성(인터프리터, C1, C2)를 미리 하여 런타임에는 바이트코드를 바로 실행하게 할 수 있다.

미리 자바 코드로 부터 네이티브 코드를 만드는 컴파일러르 AOT 컴파일러라 한다.

java 진영에서는 크게 두가지 컴파일러가 존재한다.

• jaotc 컴파일러
• graal 컴파일러

AOT vs JIT

JIT 의 단점

1. 계층형 JIT 에서는 최종 단계인 C2 까지 가기 오래 걸린다. 인터프리터 -> C1 -> C2 순이다.
2. 호출 횟수가 부족하면 C1 조차 사용하지 못할 수 있다.
3. C2 최적화는 런타임에 컴퓨팅 자원을 소모한다. 결국 유저가 쓸 컴퓨터를 뺏어쓴다.
4. 유저가 쓸 컴퓨팅 자원을 뺏어 쓰기 때문에, 오래 걸리는 최적화 작업은 하지 못한다.
   • 예를 들어 전체 프로그램을 대상으로 하는 최적화인 프로시저 간 분석은 아주 오래 걸린다. JIT 는 이 분석의 일부분만 수행할 수 있다.
   • 또한 확실한 증거가 아닌 모니터링을 통한 가정을 통해 공격적인 최적화를 한 후 가정이 틀리면 인터프리터로 돌아가는 형태를 띤다. 이것도 런타임에 정확한 최적화를 하기엔 시간이 너무 많이 걸리기 때문이다.

최종 결과물의 코드 실행 속도가 JIT 가 AOP 보다 느린게 아니다. 결국 JIT 도 오래 실행되면 C2 컴파일의 결과로 충분히 최적화된 빠른 코드가 실행된다. 후술하겠지만 오히려 AOT 에서 할 수 없는 최적화도 가능하다. 다만 JIT 는 일정 호출 횟수가 지나야 최적화된 코드가 실행된 다는 것과 바이트 코드를 해석과 최적화를 런타임에 해야 한다는 것이 느리게 하는 요인(과정에 대한 이야기)인 것이다.

AOT 의 장점

1. 애플리케이션 실행 전에 최적화를 실행한다. 따라서 오래 걸리는 최적화(ex. 코드 전체를 분석해야 하는 최적화) 도 부담없이 가능하다.
2. 네이티브 코드를 미리 만들어 놓으므로, 애플리케이션 시작시 최적화된 코드가 바로 실행된다.
3. 애플리케이션 시작 시간 자체도 줄어든다. 바이트 코드 해석 작업이 필요 없기 때문이다.
4. (JVM 에 비해) 메모리 사용량이 적다.

JIT 의 장점

1. 모니터링 기반의 최적화
   • 객체의 (추상 클래스의)실제 타입, 주로 선택되는 조건 분기, 메서드 호출시 주로 호출되는 버전, 루프문의 반복 횟수 등은 런타임에 실제 호출을 분석하지 않고서는 모르는 정보들이다.
   • 이런 정보들로 핫코드를 특정한뒤 최적화는 AOT 에서는 하지 못한다.
2. 예측 최적화
   • AOT 의 경우 미리 네이티브 코드가 만들어진다. 런타임에 해석을 다시 하고 그런거 없다.
   • 반면 JIT 의 경우 모니터링 결과로 예측 최적화를 한 후 예측이 틀렸다면 인터프리터로 돌아갈 수 있다. 따라서 AOT 에 비해 더 급진적인 예측 최적화가 가능하다.
3. 링크 타임 최적화
   • 예를 들어 각자 컴파일된 AOT 이미지를 조합하여 애플리케이션을 구동한다 했을때, 각자 컴파일된 AOT 이미지의 클래스들은 서로를 알지 못한다. 반면 JIT 는 동적으로 클래스를 로딩하여 구동할 때 따로 컴파일된 바이트 코드라도 JIT 는 두 클래스를 조합하여 최적화가 가능하다.

AOT 의 단점

1. AOT 는 클래스 라이브러리를 동적으로 읽어들일 순 없다.
2. AOT 는 코드 양이 많다(바이트 팽창)
3. AOT 는 플랫폼 중립성이 없다. 하드웨어와 운영체제별로 다시 만들어야 한다.

AOT Compile 의 형태

1. 애플리케이션 전체를 미리 네이티브 코드로 컴파일한 후 실행하는 방법
   • ex) 현재 GraalVM 의 native-image
2. 애플리케이션에 쓸 라이브러리를 미리 컴파일 한 후 공유
   • ex) 과거 jaotc
   • ex) 현재 GraalVM Shared-Lib(참고)

AOT 실 사용 예

1. MSA
   • 크기가 작음, 높은 빈도의 개발 및 배포
   • 미리 최적화된 바이트 코드가 있다면 굳이 계층형 컴파일러의 소요 시간을 기다릴 필요 없이 최적화된 코드를 빨리 실행할 수 있음.
2. 공용 클래스 파일을 미리 로드해두는 AppCDS 와 비슷하게 Pre-Compiled Shared Library 만드는 용도.

뭐가 더 좋음?

JVM 에서 AOT 는 좀 더 최근에 개발되는 신기술 축에 속하지만 그렇다고 더 좋은건 아니다.

joatc 컴파일러는 JDK 9 에 들어와서 JDK 17 에 빠지고 GraalVM 에 편입된 후 최근에는 Galahad 프로젝트로 GraalVM 다시 JDK 에 들어올 시도를 하고 있다.

JIT, AOT 중 모든 상황에서 이게 좋다! 는 없으며, 위 장단을 잘 따져서 애플리케이션 특성에 맞게 프로파일링 후 AOT 를 도입할 수 있을 것이다.

JIT 컴파일러는 컴파일 과정에서 LIR, HIR 을 대상으로 여러가지 최적화를 진행한다.

https://wiki.openjdk.org/spaces/HotSpot/pages/11829287/PerformanceTacticIndex

이번 글에서는 JVM 밑바닥까지 파헤치기 책에 나오는 4가지 최적화를 알아 볼 것이다. 이 네가지는 아주 기본적인 최적화이다.

• 전역 코드 셰이핑 - 메서드 인라인(Inlining (graph integration))
• 언어 특화 기법 - 탈출 분석
• 증명 기반 기법 - 공통 하위 표현식 제거(Common subexpression elimination)
• 배열 경계 검사 제거

메서드 인라인

메서드 인라인은 결과가 같다면 메서드 사용처를 메서드의 구현으로 대체(inline)하는 기법이다. 메서드 인라인은 두가지 이유로 중요한 최적화다.

• 메서드 호출 비용을 없앤다.
• 다른 최적화를 적용하는 기반이 된다.

public static void foo(Object obj) {
    if (obj != null) {
        System.out.pringln("do something");
    }
}

public static void inline(String[] args) {
    Object obj = null;
    foo(obj);
}

다른 최적화의 기반이 된다는 말을 알아보자. 위 inline() 메서드는 죽은 코드(dead code) 이다. 죽은 코드 제거(흐름 인지 재작성) 최적화를 적용할 수 있어 보인다.

하지만 각각의 메서드로 보았을 때에는 죽은 코드일지 알 수 없다. foo() 입장에서는 obj 가 null 이 아닌 값이 들어올 수 있고, inline() 입장에서는 foo() 에서 의미 있는 일을 할 수도 있기 때문이다.

이 두 메서드를 인라인하게 되면 죽은 코드 제거 최적화를 할 수 있다.

public static void afterInline(String[] args) {
    Object obj = null;
    if (obj != null) { // 인라인 됨
        System.out.pringln("do something");
    }
}

코드가 아무 동작을 하지 않음이 확실해 진다. 이처럼 인라인 최적화는 다른 최적화(이 예에서는 죽은 코드 제거)를 하기 위한 기반이 된다.

java 에서의 인라인

java 의 메서드는 javac 컴파일 타임에 직접 참조로 변환되는 몇몇의 케이스를 제외하고는 모두 가상 메서드 이다.

가상 메서드는 런타임에 리시버가 확정된 후 동적 디스패치를 진행해야 한다. 어떤 클래스의 메서드가 사용될지 리시버가 확정되기 전에는 모르기 때문에 인라인을 섣불리 할 수 없다.

반면 C++ 의 경우는 모든 메서드가 기본적으로 final(비가상) 메서드다.(다형성 필요시 virtual 키워드를 붙인다) 컴파일 타임에 리시버의 타입이 정해진다. 따라서 메서드 인라이닝이 수월하다.

메서드 후보가 하나일 때

자바에서도 다형성을 사용하지 않는다면 가상 메서드라도 인라이닝을 할 수 있을 것이다. 그 방법이 final 을 붙이는 것이다. 하지만 개발자가 인라이닝 최적화를 신경쓰면서 final 을 일일히 붙이는건 좋지 않다.

따라서 JVM 레벨에서 클래스 계층구조를 분석하여 가상 메서드가 오버라이딩을 사용하는지 판단 후 인라이닝을 진행하는 기능을 제공한다.

하지만 자바에서는 동적 클래스 로딩으로 클래스 계층구조는 항상 변할 수 있다. 따라서 JIT 컴파일러는 현재 메서드 오버라이딩이 한개 뿐이라서, 인라이닝할 수 있다 라는 가정/예측 을 기반으로 인라이닝한다.

이를 guided inlining 이라 하며, 따라서 자바의 인라이닝은 급진적 예측 최적화에 속한다. 동적 클래스 로딩에 의해 클래스 계층이 바뀌면 인터프리터 모드로 돌아간다.

메서드 후보가 여러개일 때

클래스 계층 구조를 분석했을 때 오버라이딩 메서드가 하나면 위처럼 예측 컴파일을 하면 된다.

반면 만약 오버라이딩 메서드가 많아 리시버의 동적 디스패치가 필요하면 인라인 캐시 방식을 사용한다.

메서드의 호출은 vtable 을 사용하여 메서드 영역에서 실제 메서드를 찾는 동작을 줄인다. 하지만 이 동작 자체도 이 인라인 캐시로 최적화된다.

1. 메서드가 호출되면 수신자와 메서드 주소를 캐시한다.
2. 다음 메서드 호출시 수신자의 버전이 같다면 메서드 주소를 통해 메서드를 바로 호출한다.
   • monomorphic inline cache 라고 한다.
   • 인라인 되지 않은 비가상 메서드와 비교하여 버전 비교 한번의 차이가 난다.
3. 다음 메서드 호출시 수신자의 버전이 다르다면 이 또한 캐시에 저장하고 모든 캐시에서 알맞은 메서드 호출 주소를 찾아 호출한다.
   • megamorphic inline cache 라고 한다.
   • vtable 사용 방식과 부하가 같다.

호출 지점(callsite) 에 캐시를 넣는다는 점에서 인라인 캐시이다. 메서드 인라이닝과 다르다. 무언가 코드가 인라인 되는 것이 아니다.

탈출 분석

메서드 안에서 생성한 객체가 메서드 밖으로 나가냐 안나가냐를 판단하는 것을 탈출 분석이라 한다.

탈출 분석 결과는 여러가지 최적화의 기반, 근거가 된다.

탈출 수준

• GlobalEscape : 객체가 메서드 밖으로 탈출하는 경우. 다른 스레드가 참조할 수 있음.
  • 생성한 객체를 정적 필드에 저장하는 경우
  • 리턴하는 경우
  • 탈출한 객체의 필드로 넣는 경우 등
• ArgEscape : 인수 또는 인수의 필드 객체이지만 메서드를 탈출하지 않는 경우.
• NoEscape : 메서드 안에서 절대 탈출하지 않는 경우. 이 때에는 객체의 힙 할당 자체가 필요없을 수 있음.

탈출 분석 후 최적화 예시

힙 할당 대신 스택 할당

탈출 분석 결과 객체가 스레드에서 탈출하지 않는다고 확신하는 경우 객체를 힙 대신 스택에 할당할 수 있다. 메서드가 끝나 스택 프레임이 없어지면 자동으로 객체 할당 메모리가 정리되므로, 가비지 컬렉팅 비용을 많이 줄일 수 있기 때문이다.

스칼라 치환

탈출 분석 결과 객체가 메서드를 벗어나지 않는다고 확신하는 경우 객체를 스칼라 타입으로 분해하여 객체 필드 각각이 지역 변수 처럼 쓰일 수 있도록 한다.

객체 생성 비용이 줄어들며, 새로운 최적화가 가능해질 수 있다.

동기화 제거

탈출 분석 결과 다른 스레드에서 접근할 수 없는 변수가 동기화 블럭에 사용된 경우 동기화 블럭을 제거할 수 있다.

Java 의 탈출 분석

탈출 분석은 비용이 크기 때문에 Java 의 JIT 에서 적용하기 부담스럽다. 탈출 여부를 정확하게 판별하려면 복잡한 프로시저간 분석이 필요하기 때문이다.

따라서 C++ 이나 C# 에 비해 탈출 분석의 정확도가 조금 뒤떨어지는 알고리즘을 사용한다. 발할라 프로젝트의 값객체가 완성될 경우, 스칼라 치환이 좀 더 효율적이게 동작할 수 있다.

탈출 분석을 통한 스칼라 치환 예시

1. 최적화 수행 전

   public int test(int x) {
    int xx = x + 2;
    Point p = new Point(xx, 42);
    return p.getX();
   }

2. 인라인 최적화 후

   public int test(int x) {
    int xx = x + 2;
    Point p = point_memory_alloc();
    p.x = xx; // 생성자 인라인
    p.y = 42; // 생성자 인라인
    return p.x; // Point::getX() 인라인
   }

3. 스칼라 치환 : 객체 p 는 메서드 밖에서 사용되지 않는다는 탈출 분석 결과

   public int test(int x) {
    int xx = x + 2;
    int px = xx; // Point 타입 객체 p 삭제 후 스칼라 치환
    int py = 42;
    return px;
   }

4. 죽은 코드 제거 최적화 : 탈출 분석 후 스칼라 치환에 의해 바뀐 코드는 죽은 코드 제거가 추가로 가능해진다.

   public int test(int x) {
    return x + 2;
   }

탈출 분석 로그로 보기

// java -XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations Escape.java
public class Escape {

    static class Point {
        int x;
        int y;
        public Point(int x, int y) { this.x = x; this.y = y; }
        public int getX() { return x; }
    }

    public static int test(int x) {
        int xx = x + 2;
        Point p = new Point(xx, 42);
        return p.getX();
    }

    public static void main(String[] args) {
        for (int i = 0; i < 100000; i++) { // JIT 컴파일 촉발
            test(10);
        }
    }
}

• -XX:+PrintEscapeAnalysis : 탈출 분석 결과 출력
  • NoEscape(탈출 불가) 와 같은 문구 출력
• -XX:+PrintEliminateAllocations : 스칼라 치환 결과 출력
  • Scalar, Allocate 와 같은 문구 출력
• -XX:+PrintEliminateLocks : 동기화 제거 결과 출력

디버그 모드로 빌드된 JVM 에서 위 옵션을 사용할 수 있다.

공통 하위 표현식 제거

표현식 E 가 이미 평가되었고, E 에 등장하는 모든 변수값이 평가 이후 변하지 않는다면, 이후의 등장하는 표현식 E 를 공통 하위 표현식이라 한다.

int d = (c * b) * 12 + a + (a + b * c);

(cb) 와 (bc) 는 같다. 앞의 (cb) 가 계산되었다면 (bc) 는 하위 표현식으로서 제거되고 이전 결과값을 사용할 수 있다. 이를 공통 하위 표현식 제거라고 한다.

공통 하위 표현식 제거는 클래스 파일 바이트 코드 명령어 수(연산의 수)를 줄일 수 있다.

배열 경계 검사 제거

자바는 안전한 언어이다. 배열 사용시 인덱스에 크기보다 큰 값이 들어오면 IndexOfOutBoundsException 이 발생한다.

이 체크는 배열 접근마다 발생하는 작업이다. 특히 순환문이라면 이 작업으로 인한 부하가 더 커진다.

컴파일 시점에 코드를 분석하여 배열 접근이 범위를 벗어나지 않음이 확실하면, 이 범위 체크(경계 검사) 로직을 제거할 수 있다.

• 암묵적 예외 처리
• null pointer 검사
• 0 으로 나누기

같은 작업도 비슷하게 자바가 안정성을 위해 실행하는 로직이지만 JIT 컴파일시 최적화 될 수 있다.

암묵적 예외 최적화

JIT 컴파일시 검사 코드를 제거하고, CPU/OS가 던지는 하드웨어 예외(트랩) 를 이용해서 자바 예외를 처리하는 최적화

어차피 예외가 나야 하는 상황이라면, 미리 if (x==null) throw NPE; 같은 명시적 체크를 매번 넣는 대신, 실제로 문제가 발생할 때만 하드웨어 예외가 터지게 하고 그걸 자바 예외로 바꿔치기한다.

숨겨진 하드웨어 예외를 사용한다는 점에서 암묵적 이란 이름이 붙음

배열 경계 검사 제거도 암묵적 예외 최적화 방식으로 경계 검사를 제거

if (foo != null) {
    return foo.value;
} else {
    throw new NullPointerException();
}

를

try {
    return foo.value; // 체크 없이 리턴으로 변경
} catch (segment_fault) { // 하드웨어 예외 catch
    // 하드웨어 예외를 NPE 로 대체하는 핸들러
    // 스레드를 커널 모드로 변경해야 하기 때문에 느리다.
    // 따라서 JIT 모니터링 정보 상 NPE 확률이 적을때 효율적이다.
    uncommon_trap();
}

따라서 JVM 들은 각자의 방식으로 이를 구현할 수 있는데, 가장 많이 사용되는 HotSpot 에서는 세가지 방식으로 사용할 수 있다.

1. 인터프리터
2. JIT 컴파일러
3. AOT 컴파일러

인터프리터는 클래스 파일의 내용을 그대로 해석 실행하는것에 비해 JIT, AOT 컴파일러는 바이트코드에서 네이티브 코드로 해석하는 과정에서 많은 최적화가 이뤄진다.

인터프리터

• Hotspot 이 바이트 코드를 실행하는 기본적인 방법
• 단순히 바이트 코드를 해석하여 실행
• 사용 case
  • 빨리 끝나는 프로그램을 빨리 실행해야할 때
    • 따로의 최적화 과정이 없기에 JIT 에 비해 시작 시간이 빠르다.
  • 가용 메모리가 적을 때
    • JIT 컴파일러는 최적화 과정에 필요한 코드 캐시 등 메모리를 사용한다.
  • JIT 컴파일의 탈출구
    • JIT 컴파일은 속도의 이유로 (코드가 전체적으로는 어떤 형태일 것이다라는)가정에 의해 컴파일한다.
    • 새로운 클래스가 로드되고 하면서 코드 구조(상속 구조 등등)이 바뀌며 최적화 가정이 깨져 최적화를 취소해야할 경우, 인터프리터로 실행하게 된다.

JIT 컴파일러

Hotspot 코드를 발견하면 그때그때 컴파일하여 실행(Just-In-Time)

Hotspot 의 계층형 컴파일

https://www.infoq.cn/article/java-10-jit-compiler-graal

HotSpot JVM 의 JIT 컴파일러는 C1, C2 가 있다. C1, C2, 인터프리터는 각자 다른 최적화 레벨을 가지고 있다. 실행중인 바이트 코드를 시스템 상태와 호출 횟수 등에 따라 최적화 레벨을 달리하여 실행하는데, 이를 계층형 컴파일 이라 한다.

1. 인터프리터 : 최초 HotSpot 구동시 인터프리터 모드로 실행
   • 인터프리터로 실행 중 자주 실행되는 HotSpot 코드는 C1 으로 컴파일 실행
2. C1(클라이언트 컴파일러) : C2 보다 빠른 컴파일, 간단한 최적화.
   • C1 으로 실행될 때에는 호출 횟수, 컴파일 결과등을 모니터링할 수 있다. 이는 더 높은 최적화 레벨인 C2 컴파일러로 컴파일할지를 판단하는 기준이 된다.
     • no-profiling : 빠르게 끝나는(최적화가 딱히 필요없는) 메서드의 경우 사용할 수 있다.
     • limited-profiling : C2 가 이미 바쁠때에는 일부 제한적인 프로파일링을 하여 C2 로 넘어가는 코드를 줄일 수 있다.
     • full-profiling : 기본적으로는 할 수 있는 모든 프로파일링을 진행하여 필요한 경우 C2 로 보낸다.
3. C2(서버 컴파일러, Opto) : C1 보다 느린 컴파일, 공격적인 최적화(높은 런타임 성능)
   • C1 컴파일러가 바쁜 경우 일부 인터프리터에서 C2 컴파일러로 직행할 수 있다.

위 그림과 같이 보자.

컴파일러 선택 관련 옵션들

• -XX:+TieredCompilation : 계층형 컴파일 활성화(JDK 7 부터 기본값). 인터프리터, C1, C2 모두 사용
• -XX:-TieredCompilation : 계층형 컴파일 비활성화. 인터프리터&C2 사용
  • JDK 8 까지는 -client 로 C2 대신 C1 으로 고정 가능
• -XX:+TieredCompilation -XX:TieredStopAtLevel=1 : 인터프리터&C1 사용
• -XInt : 인터프리터만 사용
• -XComp : JIT 컴파일러만 사용. 시작 시간이 오래 걸릴 수 있다.

java -version java -XInt -version java -XComp -version

를 실행시켜 보자. 각각 Mixed mode, interpreted mode, compiled mode 를 볼 수 있다.

디버그를 위해 JIT 컴파일러 동작을 배제하고 싶은 경우 -XInt 로 인터프리터만 쓸 수 있고, AWS lambda 같이 빨리 끝나고 가벼운 애플리케이션 실행의 경우 C2 를 배제할 수도 있고, C2 를 대체한 Graal Compiler 를 사용하려는 경우 C1 을 배제할 수도 있다.

JIT 컴파일 대상 코드

JIT 컴파일러의 컴파일 대상이 되는 코드 유형은 두가지가 있다.

1. 여러 번 호출되는 메서드
   • 표준 JIT 컴파일 방식(메서드 전체를 컴파일)
2. 여러 번 실행되는 순환문의 본문(블록)
   • 촉발은 순환문의 블록이지만, 컴파일 자체는 메서드 전체를 컴파일
   • 온스택 치환(OSR) : 메서드 내부의 순환문 실행 도중 메서드 자체가 컴파일 되며 스택의 메서드가 대체되기 때문에 온스택 치환이라고도 한다.

핫스팟 코드 탐지 방식(호출 횟수 카운팅 방식)

• 샘플 기반 : 스레드들의 호출 상단 스택을 샘플링.
  • 쉽고 효율적임
  • 스레드 스택을 보면 메서드 호출관계를 쉽게 파악 가능
  • 정확한 횟수 측정 불가
  • 스레드가 블로킹되면 탐지 불가
  • J9 jvm 에서 사용하는 방식
• 카운터 기반 : 메서드와 코드 블록에 카운터 설정
  • 정확한 실행 횟수 기록 가능
  • 메서드 각각 카운터 설정해야함. 어려움
  • 메서드 호출 관계를 직접 얻을 수 없음
  • 핫스팟 jvm 에서 사용하는 방식

C1 컴파일러로 넘어가는 호출 횟수 임계점(핫스팟 기준)

이 기준은 인터프리터 -> C1 이다. C1 -> C2 는 복잡한 모니터링 결과에 의해 전환된다.

HotSpot 은 카운터를 기반으로 핫스팟 코드를 감지한다. JIT 컴파일 대상 코드 유형이 2가지이므로, 카운터도 2가지가 존재한다.

메서드 호출 카운터

• 클라이언트 모드(Int -> C1) : 1500회
• 서버 모드(C1 -> C2) : 10000회
• -XX:CompileThreshold 로 설정 가능
• 시간당 호출 회수를 측정한다.
• 감쇠 카운터(counter decay method invocation) : 단위 시간(반감기. counter half life time)안에 임계값에 도달하지 못한다면 카운터를 절반으로 줄임.
  • -XX:-UseCounterDecay 감쇠 카운터 비활성화. 호출 카운터를 감쇠하지 않고 절대값으로 측정
  • -XX:CounterHalfLifeTime 반감기를 초 단위로 설정 가능

back edge 카운터(순환문 블록 카운터)

• 클라이언트 모드(Int -> C1) : 13995회
  • (메서드 호출 카운터 임계값 * OSR 비율)/100
  • 메서드 호출 카운터 임계값(-XX:CompileThreshold) : 디폴트 1500
  • OSR 비율(-XX:OnstackReplacePercentage) : 디폴트 933
• 서버 모드(C1 -> C2) : 10700회
  • (메서드 호출 카운터 임계값 * OSR 비율 - 인프라 모니터링 비율)/100
  • 메서드 호출 카운터 임계값(-XX:CompileThreshold) : 디폴트 10000
  • OSR 비율(-XX:OnstackReplacePercentage) : 디폴트 140
  • 인터프리터 모니터링 비율(-XX:InterpreterProfilePercentage) : 디폴트 33
• 감쇠 없이 절대 시행 횟수 측정

OSR 의 특징 - back edge 카운터는 값 조정

위 다이어그램 두개를 비교해 보면 back edge 카운터에 의한 OSR 컴파일 요청은 메서드 호출 카운터와 다른점이 있다.

back edge 카운터는 C1 컴파일이 요청된 후에 back edge 카운터 값을 줄인다는 것이다.

둘 다 공통적으로 임계값을 넘겼을 때 컴파일이 요청되었으면 더 이상 요청하지 않아야 할 것이다. 단 OSR 컴파일의 경우 반복문 안에서 그 동작이 발생하기 때문에, 컴파일이 요청되었는가를 체크하는 일 자체가 메서드 호출 카운터에 비해 훨씬 부담되는 일이다.

따라서 back edge 카운터에 의한 OSR 컴파일 요청은 호출 횟수가 임계값을 넘은 경우 호출 횟수를 일정량 줄인다. 다시 임계치에 오르는 동안 요청이 되었는지 체크를 하지 않을 수 있다.

컴파일 과정

컴파일은 비동기

컴파일은 기본적으로 메서드 컴파일, OSR 컴파일 둘 다 백그라운드 스레드에서 비동기로 진행. -XX:-BackgroundCompilation 옵션으로 동기적으로 컴파일하도록 변경 가능. 이러면 컴파일 진행중 일시 정지됨.

C1 컴파일 과정

https://nothingcosmos.github.io/OpenJDKOverview/src/overview.html

C1 컴파일에서 바이트 코드는 다음의 과정을 거쳐 네이티브 머신 코드로 변환된다.

BytesCode -> HIR -> LIR -> Native Code(Machine Code)

위 그림을 보면 컴파일 과정에서 HIR, LIR 각각에 적용되는 최적화들이 다름을 볼 수 있다.

IR (Intermediate Representation)

최적화를 위해 컴파일 과정에서 중간에 변환되는 중간 코드.

• HIR(High IR) 은 좀 더 바이트 코드와 비슷한 고수준의 중간 언어이며, 코드 레벨의 최적화를 하기에 적합한다.
• LIR(Low IR) 은 좀 더 기계어와 비슷한 중간 언어이며, 기계어 수준의 최적화를 하기 적합하다.

바이트코드는 네이티브 머신 코드가 되기 전 중간 코드(IR. Intermediate Representation)를 거친다. JIT 컴파일 과정의 최적화는 모두 IR 을 대상으로 이뤄진다.

C2 컴파일 과정

C2 는 C1 컴파일 과정에서 수집된 모니터링 정보를 토대로, 공격적인 예측 최적화 를 적용한다.

예를 들면 다음과 같은 최적화들을 진행한다. C2 컴파일의 컴파일 과정은 상당히 복잡하다.

• 죽은 코드 제거
• 순환문 언롤링
• 순환문 표현식 호이스팅
• 공통 하위 표현 제거
• 상수 전파
• 기본 블록 재정렬

공격적 예측 최적화 확실하지 않지만 모니터링 결과를 토대로 어떠한 상황임을 예측, 가정 한 후 최적화하는 것. 가정을 확실하게 알기 위해서는 비용이 많이 들기에 지금까지의 모니터링 결과로 예측하는 트레이드 오프를 적용한 결과다.

대부분의 상황은 자바가 가상 메서드이기 때문에 발생. 런타임에 리시버가 확정되지 않아 최적화하기 힘듦. 모니터링의 결과로 대부분이 하나의 리시버로 사용됨을 알게 되면, 미래에도 하나의 리시버일 것임을 가정한 후 최적화. 다른 리시버가 들어오면 인터프리터로 실행.

해당 가정이 틀린 경우는 interpreter 모드로 도망가서 일단 실행한 후 다시 컴파일한다.

컴파일 로그로 컴파일 과정 눈으로 보기

• -XX:+PrintCompilation : 컴파일 로그
• -XX:+PrintCompilation -XX:+PrintInlining : 인라이닝 포함 컴파일 로그
• -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly : 컴파일러 어셈블리 코드
• -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+PrintOptoAssembly : 좀 더 최종 결과에 가까운 중간 코드 표현(서버 모드 가상 머신용)
• -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:+PrintLIR : 좀 더 최종 결과에 가까운 중간 코드 표현(클라이언트 모드 가상 머신용)
• -XX:PrintIdealGraphLevel=2 -XX:PrintIdealGraphFile=ideal.xml : IGV 에서 컴파일러 보기 위함
  • FastDebug, SlowDebug 로 빌드된 JVM 만 가능

-XX:+PrintCompilation 의 정보

예시

// javac Test.java
// java -XX:+PrintCompilation Test
public class Test {
    public static final int NUM = 15000;

    public static int doubleValue(int i) {
        for(int j = 0; j < 100000; j++);  // JIT 코드 최적화 과정 시연용 '빈' 순환문
        return i * 2;
    }

    public static long calcSum() {
        long sum = 0;
        for (int i = 1; i <= 100; i++) {  // doubleValue()를 100번 호출
            sum += doubleValue(i);
        }
        return sum;
    }

    public static void main(String[] args) {
        for (int i = 0; i < NUM; i++) {  // calcSum()을 15,000번 호출
            calcSum();
        }
    }
}

java -XX:+PrintCompilation Test 결과

190  306 %     3       servercompiler.Test::doubleValue @ 2 (18 bytes)
194  307 %     4       servercompiler.Test::doubleValue @ 2 (18 bytes)
194  306 %     3       servercompiler.Test::doubleValue @ 2 (18 bytes)   made not entrant
194  308       4       servercompiler.Test::doubleValue (18 bytes)
195  309       3       servercompiler.Test::calcSum (26 bytes)
195  310 %     4       servercompiler.Test::calcSum @ 4 (26 bytes)
196  311       4       servercompiler.Test::calcSum (26 bytes)
198  309       3       servercompiler.Test::calcSum (26 bytes)   made not entrant

183  303 %     3       servercompiler.Test::doubleValue @ 2 (18 bytes)
184  304       3       servercompiler.Test::doubleValue (18 bytes)
184  305 %     4       servercompiler.Test::doubleValue @ 2 (18 bytes)
185  303 %     3       servercompiler.Test::doubleValue @ 2 (18 bytes)   made not entrant
185  305 %     4       servercompiler.Test::doubleValue @ 2 (18 bytes)   made not entrant
185  306       4       servercompiler.Test::doubleValue (18 bytes)
185  304       3       servercompiler.Test::doubleValue (18 bytes)   made not entrant
185  307 %     4       servercompiler.Test::doubleValue @ 2 (18 bytes)
185  308       3       servercompiler.Test::calcSum (26 bytes)
186  308       3       servercompiler.Test::calcSum (26 bytes)   made not entrant
186  309       3       servercompiler.Test::calcSum (26 bytes)
186  310 %     4       servercompiler.Test::calcSum @ 4 (26 bytes)
187  311       4       servercompiler.Test::calcSum (26 bytes)
188  309       3       servercompiler.Test::calcSum (26 bytes)   made not entrant

IGV

Ideal Graph Viewer.

JIT 컴파일 과정에서 코드는 Ideal Graph 라는 형태로 표현된다. IGV 플러그인을 사용하면 이 그래프를 컴파일 단계별로 시각적으로 볼 수 있다. 이를 이용하면 컴파일 과정에서 최적화가 어떻게 되는지 시각적으로 볼 수 있다.

IGV 는 JDK 소스 코드에 이미 포함되어 있다. 다만 제공되는 런타임에는 없기에, 소스코드를 받아서 직접 빌드하여 실행하도록 한다.

IGV 는 JDK 소스코드에 포함. 빌드하여 사용 $ cd src/utils/IdealGraphVisualizer $ mvn install $ chmod u+x igv.sh $ ./igv.sh

이 그림에서는 빨간부분이 위 테스트 코드 doubleValue() 의 빈 순환문이며, 없어졌다는 뜻이다.

제네릭

Object obj = "a";
Object[] strArr = new String[10]; // 공변
strArr[1] = 10; // 런타임 할당시 에러

배열은 공변이다. String 이 Object 의 하위 타입이라면 String[] 도 Object[] 의 하위 타입이다. 따라서 Object[] 정적 타입 변수에 String 값을 추가하는 것은 컴파일 타임에 에러를 낼 수 없다.

ArrayList list = new ArrayList();
list.add(Integer.valueOf(10)); // 컴파일, 런타임 에러 X
list.add("b"); // 컴파일, 런타임 에러 X

제네릭이 있기 전 ArrayList(컬렉션) 은 타입이 없다. 따라서 하나의 컬렉션에는 여러 타입을 넣을 수 있다.

제네릭 도입시 문제 - 하위 호환성

매개 변수화 된 타입인 제네레릭은 타입에 국한되지 않은 추상적인 코드를 만들 수 있게 한다. 하지만 위 처럼 제네릭이 있기 전의 컬렉션은 모든 타입을 받았다.

제네릭 컬렉션을 만들면서 기존 컬렉션 코드를 문제되게 하지 않으려면,

1. 기존 컬렉션을 두고 새로운 제네릭 컬렉션을 새로 만든다.
2. 기존 컬렉션을 제네릭 버전으로 변경하고, 런타임에는 타입 소거한다. 런타임에는 적절한 형변환 코드를 넣어서 해당 타입만이 들어감을 보장한다.

자바는 2번을 선택했다. JDK 1.2 시절 Vector -> ArrayList, HashTable -> HashMap 과 같이 1번의 선택으로 컬렉션 라이브러리를 이미 변경한 탓에 또 1번을 선택하면 Vector<Int>, ArrayList<Int> 와 같이 너무 많은 클래스가 생겨 불편하기 때문이다.

이를 타입 소거 라고 한다.

타입 소거의 문제1 - 박싱/언박싱

제네릭 컬렉션에서 객체 타입을 써야하는 이유

하위 호환성을 위한 타입 소거로 인해 제네릭 컬렉션의 타입 제한은 컴파일 타임에 형변환 코드 가 자동 생성되어 동작한다.

문제의 원인은 자바 컬렉션 라이브러리는 내부에서 애초에 Object[] 를 사용했다는 것이다. ArrayList 의 add는 아래 처럼 Object[] 에 값을 저장한다. 따라서 요소는 Object 의 하위 타입이어야 한다.

    private void add(E e, Object[] elementData, int s) {
        if (s == elementData.length)
            elementData = grow();
        elementData[s] = e;
        size = s + 1;
    }

타입 변환 으로 제네릭을 구현한 이상 제네릭 컬렉션의 모든 요소는 Object 타입의 하위 타입이어야 한다는 결론이 난다.

이것이 제네릭에서 기본 타입을 쓰지 못하는 이유다. primitive 타입은 object 의 하위가 아니기 때문이다. 타입 소거 방식을 택할 수 밖에 없었기 때문에 발생한 문제다.

박싱/언박싱의 문제

다행히 원소로 객체 타입만을 쓸 수 있다는 문제는 코드 레벨에서는 없다. primitive 타입을 원소를 add 하는 코드를 작성하더라도 박싱/언박싱을 자동으로 해주기 때문이다.

진짜 문제는 박싱/언박싱 자체가 느리고 양도 많아서, 자바 제네릭의 주요한 성능적 문제라는 것이다.

문제 해결의 노력 - 발할라 프로젝트

박싱/언박싱을 근본적으로 없애기 위해서는 다음 중 하나가 만족되어야 한다.

• 런타임에 제네릭 타입을 유지(reified generics) 해서 List<int>와 List<Object>를 다른 클래스로 다루기
• primitive마다 특수화된 버전(예: ListInt, ListDouble…)을 자동 생성
• JVM의 값 타입(value type) 지원

이상의 방식은 모두 타입 자체를 유지하여 타입 소거가 되지 않도록 하는 방법이다. 외에도 여러 방식이 있다.

이 작업은 발할라 프로젝트라는 이름으로 진행중이다. 오랫동안.

타입 소거의 문제2 - 런타임에 엘리먼트의 타입을 알 수 없음

class Test {
    List<String> list;
}

위 list 의 제네릭으로 선언된 원소 타입 <String> 은 런타임에 알 수 없다. 타입이 소거되기 때문이다. 따라서 필요하다면 인자로 가지고 다녀야 한다.

다만 Signature 클래스 파일 속성에 제네릭 컬렉션 전체 타입이 적히긴 한다. 우린 리플렉션으로 이를 사용할 수 있다.

Field f = Test.class.getDeclaredField("list");
System.out.println(f.getGenericType());
// 결과 : java.util.List<java.lang.String>

getGenericType() 의 리턴값에서 String 만 따로 추출할 방법은 없다. 정말 필요하다면 파싱을 해야 한다.

타입 소거의 문제3 - 오버로딩 불가

public void sum(List<Integer> a) {}
public void sum(List<Double> a) {}

위 두 메서드의 시그니쳐는 분명히 다르지만 오버로딩이 불가하다. 런타임에는 둘의 타입 매개변수가 소거되므로 두 시그니쳐가 같아지기 때문이다.

애너테이션 프로세서

애너테이션 프로세서는 컴파일 동작을 개발자가 간섭할 수 있는 기능이다. 간단하게는 코드를 자동으로 추가하는 기능이며 정확하게 말하면 컴파일 타임에 추상 구문 트리를 수정하는 기능이다.

• AbstractProcessor 를 구현하여 javac -processor [구현체 클래스] 로 실행한다.
• 다음 등등의 동작이 가능
  • ProcessingEnvironment 의 Messager 로 컴파일시 에러 레벨을 지정하여 메세지를 출력
  • 에너테이션을 읽어서 값을 보고 메서드 생성(롬복)
  • 등등
• 애너테이션 정보를 런타임에 사용하는 spring AOP 와 애너테이션 사용의 쌍두마차라 할 수 있다.
• 대표적인 사용처로는 롬복, 하이버네이트 validator 등이 있다.

// 아래 애너테이션 둘다 필요
@SupportedAnnotationTypes("*") // 프로세서에 사용할 애너테이션 클래스 지정
@SupportedSourceVersion(SourceVersion.RELEASE_17)
public class CustomAnnotationProcessor extends AbstractProcessor {

    // 찾은 요소에 대해 실행할 클래스. 따로 적진 않을 예정
    // 예시의 구현은 ProcessingEnvironment 의 messager 를 이용한 컴파일 에러 출력
    private Validator validator;

    @Override
    public synchronized void init(ProcessingEnvironment processingEnv) {
        super.init(processingEnv);
        validator = new Validator(processingEnv.getMessager());
    }

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        if (!roundEnv.processingOver()) {

            // 프로세서 대상을 선택한다. 이 예시에서는 루트 요소만을 검사한다.
            // 애너테이션을 대상으로 하려면 getElementsAnnotatedWith() 를 사용한다.
            Set<? extends Element> rootElements = roundEnv.getRootElements();

            for (Element element : rootElements) {
                validator.validate(element);
            }
        }
        return false;
    }
}

어휘 및 구문 분석

어휘 분석 : int a = b + 2 와 같은 코드를 int, a, = , b, +, 2 와 같이 토큰으로 분리한다.

구문 분석 : 토큰으로 추상 구문 트리 만든다. 추상 구문 트리는 코드를 기계가 더 이해하기 쉬운 데이터 구조이며, 이후 컴파일 레벨의 작업은 모두 추상 구문 트리를 대상으로 이뤄진다.

어휘 및 구문 분석에는 구조적으로 올바른지 체크하고 문제가 있다면 예외를 발생한다.

intellij 의 PsiViewer 플러그인을 사용하면 추상 구문 트리를 시각적으로 볼 수 있다.

심벌 테이블 채우기

심벌 테이블 : 심벌 주소와 심벌 정보의 집합

• 의미 분석 과정에서 이름을 원래 선언과 일치하게 사용하는지 확인 한다던가
• 주소 할당할 때 쓰임

기본 생성자가 만들어지는 타이밍이기도 하다.

애너테이션 처리

플러그인된 애너테이션 처리기의 처리를 진행한다.

애너테이션 처리기(processor) : 컴파일 타임에 애너테이션을 보고 바이트 코드를 생성하는 기술

• 자바 코드로 AbstractProcessor 를 구현하여 만들 수 있음
• AbstractProcessor 는 컴파일 타임에 구현에 의해 추상 구문 트리를 수정
• 개발자가 컴파일 시점의 동작을 추가할 수 있다는 것

대표적으로 애너테이션은 런타임에 처리되는 Spring AOP 를 생각할 수 있다. 애너테이션 처리기는 컴파일 타임에 애너테이션을 활용하는 방법이다.

이 단계에서 추상 구문 트리의 수정이 발생하면 구문 분석 및 심벌 테이블 채우기 단계를 다시 실행해야 한다.

의미 분석과 바이트코드 생성

이 단계의 추상 구문 트리는 구조적으로 올바른 상태이다.

의미 분석 단계에는 맥락상 논리적으로 올바른지 체크한다. (구조적으로 이상하게 작성한게 아닌)보통의 컴파일 타임 에러는 이 단계에서 체크된다.

의미 분석 - 특성 검사

변수를 사용하기 앞서 선언이 되어 있는지 변수와 할당될 데이터의 타입이 일치하는지

상수 접기 최적화(1 + 2 -> 3 으로 컴파일)

의미 분석 - 데이터 흐름 분석과 제어 흐름 분석

프로그램이 맥락상 논리적으로 올바른가를 체크

• 지역변수가 사용되기 전에 값이 할당되었는지
• 메서드의 모든 실행 경로에서 값을 반환하는지
• checked 예외가 모두 올바르게 처리되었는지
• 등등..

클래스 로딩 시의 제어 흐름 분석 검증과 비슷하지만 범위가 다르다.

지역 변수의 final 로 예를 들어 보자. 필드의 final 은 필드 테이블에 플래그로 final 임이 저장된다. 따라서 런타임에 해당 필드가 변경되면 에러를 낼 수 있다. 반면에 지역 변수 테이블에 저장되는 지역 변수는 클래스 파일에는 단순한 심벌 참조만이 존재하므로 런타임에 지역 변수가 final 임을 알 수 없다. 즉, 지역 변수의 final 은 컴파일 타임에만 검사된다.

편의 문법 제거

런타임에는 영향을 주지 않고 더 효율적인 코딩만을 위한 코드를 편의 문법이라 한다. 컴파일 타임의 이 단계에서는 해당 편의 문법을 제거한다.

편의 문법의 예는 다음과 같다.

• 제네릭
• 가변 인자
• 오토박싱/언박싱

바이트코드 생성

지금까지의 정보로 바이트코드를 생성한다.

인스턴스 생성자 <init>(), <clinit>() 은 이 단계에서 추가된다.

동적 타입 언어에는 대표적으로 자바스크립트, 루비 등이 있고 정적 타입 언어에는 대표적으로 자바, C++ 이 있다.

무슨 차이일까?

정적 타입 언어

• 정적 타입 언어
  • 변수와 값 모두 타입이 있다.
  • 타입 검사 과정의 주요 단계들이 컴파일 타임 에 수행된다.

public class CustomPrintStream extends PrintStream {

    public CustomPrintStream(OutputStream out) {
        super(out);
    }

    public static void main(String[] args) {
        PrintStream obj = new CustomPrintStream(System.out);
        obj.print("Hello");
    }
}

obj 변수의 정적 타입은 PrintStream 이다. 변수 obj 에 들어갈 값의(런타임에) 실제 타입은 PrintStream 또는 그 하위일 것이다.

print 메서드 입장에서 생각해보면, 수신 객체인 obj 의 정적 타입은 컴파일 타임에 PrintStream 으로 정해진다. 이는 컴파일의 결과인 클래스 파일에서도 볼 수 있다.

 0: new           #7                  // class indy/CustomPrintStream
 3: dup
 4: getstatic     #9                  // Field java/lang/System.out:Ljava/io/PrintStream;
 7: invokespecial #15                 // Method "<init>":(Ljava/io/OutputStream;)V
10: astore_1
11: aload_1
12: ldc           #16                 // String Hello
14: invokevirtual #18                 // Method java/io/PrintStream.print:(Ljava/lang/String;)V

14 인덱스 invokevirtual 을 보면 메서드의 타입이 java/io/PrintStream.print:(Ljava/lang/String;)V 로 정해진다. 즉, 수신 객체 변수의 정적 타입이 정확하게 정해진 것이다.

따라서, 만약 수신 객체에 없는 메서드를 호출한다면 컴파일 타임에 에러가 발생한다.

동적 타입 언어

• 동적 타입 언어
  • 값에만 타입이 있고 변수에는 타입이 없다.
  • 타입 검사 과정의 주요 단계들이 런타임 에 수행된다.

obj.print("Hello")

위 코드에서 obj 변수에는 타입이 없다. 런타임에 실제 객체가 정해질 때 까지는 아무것도 알 수 없다. 따라서 컴파일 타임에 알 수 있는 메서드에 대한 정보는 메서드 이름, 매개변수의 이름, 리턴 표현식 정도 밖에 없다. 즉, 수신 객체 (this) 를 정할 수 없다.

그렇기에 obj 변수로 어떤 메서드를 호출하더라도 컴파일 타임에는 문제가 되지 않는다.(문제를 잡을 수 없다) 코드 흐름상 런타임에 obj 값으로 print 메서드가 없는 객체만 할당됨이 분명하더라도, 컴파일 타임에는 에러가 발생하지 않는다.

JVM의 동적 타입 언어 지원

JVM 은 바이트코드만 만들 수 있다면 작성되는 언어가 어떤 것이든 상관 없다. 애초에 JVM 은 여러 언어를 지원하려는 계획이 있었다.

JDK 7 이전의 메서드 호출 명령어(invokestatic, invokevirtual, invokespecial, invokeinterface) 들은 위처럼 수신 객체의 완전한 정적 타입을 인자로 받았다.

하지만 동적 언어는 수신 객체의 타입을 런타임 에 정할 수 있어야 한다. 따라서 JDK 7 이전에는 동적 언어에 대한 지원이 시원찮았다. 억지로 동적 언어의 흉내는 낼 수 있었는데, 예를 들면 런타임에 껍데기 객체를 넣어두고 런타임에 필요한 객체 바이트 코드를 동적으로 생성해서 집어넣으면 된다. 다만 바이트 코드 생성을 런타임에 하게 되므로 성능적 부하가 있었다.

또한 런타임에 정적 타입이 확정되지 않으므로 JIT 컴파일러가 인라인 최적화를 하지 못했다. 수신 객체의 결정(동적 바이트코드 생성)은 당연하게도 JIT 컴파일러 인라인 최적화 이후에 이뤄지기 때문이다. 한번 실행시켰을때 타입이 나오니 그 때 타입을 캐싱해두면 또 가능하긴 하다면 캐시는 무한정이 아니다. 어찌되었든 오버헤드다.

JSR 292

자바는 동적 언어를 지원하기 위해 JSR 292 를 내놓았다.

컴파일 타임에는 기존 invoke~ 명령어들 처럼 매서드 수신 객체의 타입이 아닌 메서드 이름, 매개 변수 타입, 리턴 타입에 대한 심벌 참조만 남겨 놓고 (상수풀의 CONSTANT_invokedynamic_info) 런타임에 실제 실행할 메서드를 결정하는 것이다.

메서드 해석 책임을 가상 머신으로부터 특정한 사용자 코드로 옮기는 역할

또한 이 때 JIT 컴파일러의 인라인을 포함한 최적화가 가능한 구조로 만들어졌다.

이 제안이 JSR 292 이며 invokedynamic 이다. 구체적으로는 두가지가 제안되었다.

1. invokedynamic 바이트코드 명령어
2. java.lang.invoke 패키지

invokedynamic 구현

invokedynamic 을 이용한 메서드의 동적 선택은 다음 네가지 요소로 이뤄진다.

1. CONSTANT_invokedynamic_info
2. BootStrap
3. Callsite
4. MethodHandle

MethodHandle

java.lang.invoke 에 포함된 클래스. 만들어진 MethodHandle 객체는 하나의 메서드를 가리키게 된다. 메서드를 특정하기 위해 클래스, 메서드 이름, 리턴 타입, 매개변수 타입 를 사용한다. Method 타입의 리플렉션과 비슷하다.

public class MethodHandleTest {

    public String test(int a, int b) {
        return  String.valueOf(a) + b;
    }

    public static void main(String[] args) throws Throwable {
        MethodType mt = MethodType.methodType(String.class, int.class, int.class);
        MethodHandle mh = MethodHandles.lookup()
                .findVirtual(MethodHandleTest.class, "test", mt) // (1) invokevirtual 메서드 찾기
                .bindTo(new MethodHandleTest()); // (2) 리시버(수신 객체) 지정

        Object res = mh.invoke(33, 2);
        System.out.println(res);
    }
}

다만 메서드 리플랙션은 메서드에 대한 포괄적인 정보를 가지고 있고 무겁다. MethodHandle 은 메서드를 실행하는데 필요한 정보만 가지고 있어 가볍기 때문에, 리플렉션의 일부를 대체할 수 있다.

중요한건 (2) 주석 부분이다. 테스트 코드에서는 test 라는 이름을 가진 메서드를 찾고 있고 해당 메서드를 가진 객체를 수신 객체로 지정했다. 수신 객체를 다음과 같이 아무 메서드가 없는 클래스의 객체로 바꿔보자.

// public class Test {}
.bindTo(new Test());

컴파일 타임에는 아무 에러도 나지 않는다.(런타임에 에러가 난다) 동적 타입 언어와 같이 컴파일 타임에는 수신 객체의 타입을 검사하지 않는다.

자바의 해결책은 클래스 파일의 심벌 참조만으로 런타임에 동적 타입 언어의 기능을 지원하는것이라 했다. 위 코드에서 MethodHandle, MethodType 에 들어가는 매개변수들을 보면 심벌 참조(CONST_invokedynamic_info)에 있는 정보임을 알 수 있다. 심벌 참조만 있으면 MethodHandle 을 이용하여 동적으로 메서드를 찾을 수 있다는 말이다.

CallSite

마찬가지로 java.lang.invoke 에 포함된 클래스. MethodHandle 하나를 필드로 가지는 래퍼다.

MethodHandle 은 수신 객체까지 구체적으로 지정된 메서드 표현이다. 딱 한 객체의 한 메서드를 가리킨다.

동적 타입 언어라면 컴파일 타임의 심벌 참조가 런타임에 여러 메서드(MethodHandle)로 동적 변경 이 가능해야 한다. 이 역할을 해주는 래퍼가 CallSite 이다.

CallSite 에 대해 정리하자면 다음과 같다.

1. CallSite 는 MethodHandle 을 포워딩해주는 객체다. invokedynamic 은 CallSite 객체를 본다.
2. CallSite 는 setType() 메서드를 통해 자신이 가진 MethodHandle 을 변경할 수 있다.
3. invokedynamic 은 첫 호출시 이후 설명할 BootStrapMethod 를 실행하여 CallSite 를 만든다. 두번째 호출부터는 CallSite 를 통해 MethodHandle 로 빠르게 바로 접근할 수 있다.
4. MethodHandle 이 변경될 수 있다면 Jit 컴파일러가 인라인 최적화를 무조건적으로 할 수 없다. CallSite 는 이를 대응하는 구조를 가진다.
   • Jit Compiler 는 일단 MethodHandle 이 바뀌지 않을 것이라 가정하고 낙관적으로 인라인 최적화를 진행한다. 한번 정해진 MethodHandle 은 한동안 바뀌지 않을 것이라는 가정이다. 내부적으로 바뀜을 감지하는 필드를 가지고 있다가 MethodHandle 이 바뀌면 그 때 인라인을 다시 한다.
   • CallSite 는 abstract 클래스다. setType() 이 가능한 MutableCallSite 과 setType() 호출시 예외로 막혀있는 ConstantCallSite 하위 클래스가 있다. ConstantCallSite 는 MethodHandle 이 바뀌지 않을 때 사용한다. 이 때에는 위의 MethodHandle 변경 감지를 스킵할 수 있다.

BootStrapMethod

BootStrapMethod 는 클래스 파일의 심볼 참조를 받아서 CallSite 를 반환하는 메서드다. invokedynamic 은 이 메서드를 호출하여 CallSite 를 받은 뒤 이후 호출시 CallSite 를 통해 메서드를 실행한다.

java 언어 중 invokedynamic 을 사용하는 string concat 구문을 예시로 보자.

public class StringConcator {

    public String concat(String a, String b) {
        return a + b;
    }
}

아래는 위 코드 클래스 파일의 일부이다.

    Code:
        ...
         2: invokedynamic #7,  0     // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;


BootstrapMethods:
  0: #19 REF_invokeStatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #25 \u0001\u0001
InnerClasses:
  public static final #32= #28 of #30;    // Lookup=class java/lang/invoke/MethodHandles$Lookup of class java/lang/invoke/MethodHandles

클래스 파일에는 invokedynamic 이 실행되었을때 어떤 BootStrapMethod 가 실행되어야하는지 명시된다. a + b 처럼 StringBuilder 구문을 사용하면 StringConcatFactory.makeConcatWithConstants() 메서드가 BootStrapMethod 로 쓰인다고 명시되어 있다. 이는 Javac 컴파일러가 만들어낸 것이다.

    public static CallSite makeConcatWithConstants(MethodHandles.Lookup lookup,
                                                   String name,
                                                   MethodType concatType,
                                                   String recipe,
                                                   Object... constants)
        throws StringConcatException

위는 makeConcatWithConstants 의 시그니처다. 메서드 이름과 매개 변수 타입, 리턴 타입 등을 받아서 CallSite 를 반환한다.

이제 동작이 어떻게 이뤄지는지 알 수 있다.

1. invokedynamic 이 실행되면 호출할 BootStrapMethod(위 예시에서 StringConcatFactory.makeConcatWithConstants(). CallSite 를 반환하는 함수) 를 원하는 동적 메서드 동작에 맞게 자바로 구현한다. 동적 언어 구현인 CallSite, MethodHandle 도 구현되어야 할 것이다.
2. JRuby 같은 동적 타입 언어의 컴파일러 구현을 한다. 원하는 언어 구문을 컴파일하면 클래스 파일 BootStrapMethods 속성에 1번에서 구현한 BootStrapMethod 를 사용하도록 하면 된다.

이와 같이 언어 컴파일러와 자바 코드를 작성 함으로서 개발자가 디스패치 로직을 결정할 수 있다.

자바 언어에서의 이득

원래 invokedynamic 은 동적 타입 언어를 위해 만들어졌으나, 자바 언어에서도 유용하게 써먹고 있다.

1. 람다
2. StringBuilder 의 대체. StringConcat
3. Record
4. 리플렉션의 대체

참고

리플랙션 대안으로서의 MethodHandle https://www.itworld.co.kr/article/3568004/%EB%A6%AC%ED%94%8C%EB%A0%89%EC%85%98%EB%B3%B4%EB%8B%A4-%EB%82%AB%EB%8B%A4-%EC%9E%90%EB%B0%94%EC%9D%98-%EB%A9%94%EC%86%8C%EB%93%9C-%ED%95%B8%EB%93%A4%EA%B3%BC-%EB%B3%80%EC%88%98-%ED%95%B8%EB%93%A4.html

invokedynamic jdk 발표 ppt https://cr.openjdk.org/~vlivanov/talks/2015-Indy_Deep_Dive.pdf

Deep Static Modeling of invokedynamic https://yanniss.github.io/invokedynamic-ecoop19.pdf

baeldung https://www.baeldung.com/java-invoke-dynamic

컴파일된 클래스 파일에는 호출할 메서드의 이름(FQCN)이 적혀있다.

JVM 런타임에는 해당 이름의 메서드는 여러개가 존재할 수 있다. (오버라이딩, 오버로딩) 클래스 파일의 단순 이름인 심벌 참조를 런타임에 존재하는 같은 이름을 가진 1개 이상의 버전의 메서드 중 어떤 것을 실행할지 고르는 작업은 해석과 디스패치가 있다.

호출할 메서드 선택 - 정적 해석

클래스 파일을 만드는 컴파일 타임에 어떤 버전의 메서드를 선택할지 정해지는 경우가 있다. 이를 정적 해석이라 한다.

• invokestatic : static 메서드
• invokespecial : private 메서드, 인스턴스 생성자, 부모 클래스의 메서드
• invokevirtual : final 한정자가 붙은 메서드 only

위 세가지 메서드 실행 바이트코드 명령어의 다섯가지 케이스는 컴파일 타임에 메서드의 버전이 정해지는 정적 해석이다.

다르게 말하면, 이 메서드들은 오버라이딩이 불가하므로 컴파일 타임에 어떤 메서드를 사용할지 정해진다.

이러한 메서드들을 비가상 메서드라 한다. 이후 나올 나머지 메서드들은 모두 가상 메서드이다.

static 메서드 같은 경우 오버로딩이 가능하긴 하나 정적 디스패치인 오버로딩 또한 컴파일 타임에 메서드가 정해지므로 정적 해석이라 봐도 될 것이다.

호출할 메서드 선택 - 디스패치

자바는 오버로딩과 오버라이딩을 지원한다. 클래스 파일에 명시된 메서드 이름을 가진 런타임의 여러 메서드 버전 중 하나를 골라 호출하는 것을 디스패치 라 한다.

위의 정적 해석과는 다른 수준의 메서드 선택이다.

디스패치는 정적/동적, 단일/더블로 나뉜다.

• 정적 단일 디스패치
• 정적 더블 디스패치
• 동적 단일 디스패치
• 동적 더블 디스패치

자바에서 위 네개를 다 지원하는게 아니라 언어 무관하게 개념적으로 그렇다는 것이다.

정적 디스패치는 컴파일 타임에 이뤄진다. 엄연하게는 정적 해석이다. 그러나 많은 곳에서 오버라이딩, 오버로딩과 연관지어 설명하기 위해 동적이라는 의미를 가진 디스패치와 묶어서 설명된다.

정적 타입과 실제 타입

디스패치를 이해하기 위해선 정적 타입과 실제 타입을 다시 이해하고 가면 좋다

abstract class Human {}
class Man extends Human {}
class Woman extends Human {}

Human h = new Man();

위 h 객체의 정적 타입은 Human, 실제 타입은 Man 이다.

실제 타입은 런타임에 변할 수 있다. 정적 타입은 컴파일 타임부터 정해지는 값이다. 디스패치를 이해하기 위해선 이 개념이 중요하다. 아래 코드를 보자.

Human h = (new Random()).nextBoolean() ? new Man() : new Woman();

런타임의 random 실행값에 따라 실제 타입은 변할 수 있지만, 정적 타입은 Human 으로 고정된다.

정적 디스패치

컴파일 타임에 정적 타입 을 보고 메서드 버전을 결정하는 것을 정적 디스패치라 한다. 자바에서 정적 디스패치의 가장 일반적인 사용처는 오버로딩이다.

class StaticDispatch {
    // 오버로딩 1
    public void hello(Human human) {
        System.out.println("Hello, human!");
    }

    // 오버로딩 2
    public void hello(Man man) {
        System.out.println("Hello, man!");
    }

    // 오버로딩 3
    public void hello(Woman woman) {
        System.out.println("Hello, woman!");
    }
}

Human m = new Man();
Human w = new Woman();
StaticDispatch sd = new StaticDispatch();
sd.hello(m);
sd.hello(w);

// 결과 : 둘 다 오버로딩 1 실행
// Hello, human!
// Hello, human!

정적 타입은 Human 이지만 실제 타입이 Man, Woman 인 두 객체를 생성하였다. 오버로딩 된 메서드를 실행한 결과를 보면 둘 다 인자를 Human(정적 타입) 인 메서드가 실행되었다.

이유는, 컴파일러는 오버로딩된 메서드 선택시 인자로 전달된 객체의 정적 타입을 보고 판단하기 때문이다.

동적 디스패치

런타임에 수신 객체의 실제 타입을 알아내어 메서드 버전을 결정하는 것을 동적 디스패치라 한다. 자바에서 동적 디스패치의 가장 일반적인 사용처는 오버라이딩이다.

abstract class Human {
    abstract void hello();
}

class Man extends Human {
    @Override
    void hello() {
        System.out.println("hello, man!");
    }
}

class Woman extends Human {
    @Override
    void hello() {
        System.out.println("hello, woman!");
    }
}

Human m = new Man();
Human w = new Woman();

m.hello();
w.hello();

m = new Woman();
m.hello();

// 결과
// hello, man!
// hello, woman!
// hello, woman!

여러 하위 타입의 오버라이딩 된 메서드 중 하나를 선택하기 위해서는 정적 타입만으로는 불가능하다. 수신 객체의 실제 타입을 먼저 판단해야 한다. 수신 객체의 실제 타입을 판단함으로서 오버라이딩 된 메서드 중 하나를 고르는 과정에 동적 디스패치가 동작한다.

// main 클래스 javac, javap -verbose 중 일부

상수풀
#13 = Methodref          #14.#15        // dispatch/Human.hello:()V

Code Attribute
 17: invokevirtual #13                 // Method dispatch/Human.hello:()V
 21: invokevirtual #13                 // Method dispatch/Human.hello:()

위는 main 클래스 바이트 코드 일부이다. 보다시피 invokevirtual 명령어는 인자로 메서드의 심볼 참조를 갖는다. Code Attribute 의 17 인덱스는 m.hello() 코드와 대응되고, 21 인덱스는 w.hello() 코드와 대응되는데, 컴파일 타임에는 이 둘의 차이가 없다. (상수풀의 같은 메서드 심볼 참조를 인자로 갖는다)

컴파일 타임에는 아무런 메서드 선택이 일어나지 않는다는 이야기다.

반면 런타임에는 invokevirtual 바이트코드 명령어가 실행되며 실제 메서드 선택이 일어난다. 이는 동적 디스패치는 invokevirtual 의 동작에서 기인한다.

invokevirtual 동작

1. 피연산자 스택 상단 첫번째 요소가 가리키는 객체의 실제 타입 을 찾는다.
2. 실제 타입의 클래스 파일에서 상수(#13) 의 서술자와 이름이 일치하는 메서드를 찾는다.
3. 메서드가 존재하고, 접근 권한이 있다면 해당 메서드의 직접 참조를 반환한다.
4. 메서드가 존재하지 않는다면 상속 계층을 따라 상위 클래스로 가서 찾는다.
5. 최상위 클래스까지도 서술자와 이름이 일치하는 메서드를 찾지 못하면 AbstractMethodError 를 던진다.

invokevirtual 은 메서드 호출 명령어다. 필드는 아니다. 동적 디스패치의 근본은 Invokevirtual 동작이기 때문에, 필드에 대해선 오버라이딩이 없는 것.

단일 디스패치와 더블 디스패치

단일/더블 디스패치를 나누는 기준은 수신 객체 와 매개 변수 중 몇가지를 디스패치의 메서드 결정에 사용하느냐다.

public class Dispatch {
    static class QQ {}
    static class _360 {}

    public static class Father {
        public void hardChoice(QQ arg) {
            System.out.println("Father chose a qq");
        }

        public void hardChoice(_360 arg) {
            System.out.println("Father chose a 360");
        }
    }

    public static class Son extends Father {
        public void hardChoice(QQ arg) {
            System.out.println("Son chose a qq");
        }

        public void hardChoice(_360 arg) {
            System.out.println("Son chose a 360");
        }
    }
}

Father father = new Father();
Father son = new Son();
Son son2 = new Son();

father.hardChoice(new _360());
son.hardChoice(new QQ());
son2.hardChoice(new QQ());

// 결과
// Father chose a 360
// Son chose a qq
// Son chose a qq

자바의 정적 디스패치는 더블 디스패치다

위 코드의 클래스 파일의 일부를 보자.

32: invokevirtual #16    // Method Dispatch$Father.hardChoice:(LDispatch$_360;)V
43: invokevirtual #23    // Method Dispatch$Father.hardChoice:(LDispatch$QQ;)V
54: invokevirtual #26    // Method Dispatch$Son.hardChoice:(LDispatch$QQ;)V

위 세줄은 정적 디스패치에 의해 정해진 메서드 버전을 보여준다. 변수의 정적 타입에 따라 Father. 또는 Son. 이 정해진다. 또한 매개 변수의 타입에 따라 인지의 QQ 또는 360 이 정해진다.

즉 수신 객체와 매개 변수 둘 다 보고 메서드를 결정하므로 더블 디스패치이다.

자바의 동적 디스패치는 단일 디스패치다

컴파일 타임에 정적 디스패치에 의해 매개 변수의 타입은 정해졌다. 런타임에는 오버라이딩 된 메서드 중 어떤 클래스의 메서드를 사용하면 되느냐만 결정하면 된다.

이는 동적 디스패치에서 설명했듯, 수신 객체의 실제 타입 을 보고 결정한다.

따라서 자바의 동적 디스패치는 수신 객체 하나만 보면 되므로 단일 디스패치이다.

자바 동적 디스패치 최적화 - vtable

(Child Class vtable 의 offset 0 의 Address 가 0x1000 이 되어야 하지 않나 싶다.) https://medium.com/@devjohnpark/java-method-call-process-and-dispatch-cded3f2c3103

vtable 은 C++, 자바등 동적 디스패치를 최적화하는 기법 중 하나다.

동적 디스패치는 런타임에 실제 타입이 어떤것일지 모르므로 컴파일 타임에는 심벌 참조만 남기고 런타임에 직접 참조로 바꾼다고 했다.

더욱이 객체의 실제 타입은 런타임에 언제든 바뀔 수 있으므로, 메서드 호출마다 항상 invokevirtual 을 실행해야 한다. Method Area 의 클래스 메타 데이터에서 호출하고자 하는 메서드의 시그니처에 적합한 메서드를 찾는 동작을 invokevirtual 마다 해야한다는 이야기다.

클래스 안에 메서드가 n 개 있다면 한번 찾는 동작은 O(n) 의 시간 복잡도를 가진다. invokevirtual 이 실행될 때 마다 O(n) 의 탐색이 이뤄질 것이다. 이는 메서드 수가 많아질수록 느린 동작이 된다.

Vtable

이 문제를 해결하기 위해 각 클래스 메타데이터는 vtable 이라는 테이블 구조체를 가진다.

vtable 메서드의 address 를 가지고 있는 캐시다.

vtable 은 [index : method_address] 데이터를 담고 있으며 메서드 호출시 또는 클래스 로딩시 (jvm 구현에 따라 다름) 채우게 된다.

invokevirtual 이 호출되어 심벌 참조를 보고 Method Area 에서 직접 참조를 읽어오면, 그 안에는 vtable 의 index 가 있다. (Method) vtable[인덱스] 를 하면 O(1) 의 속도로 빠르게 메서드의 실제 주소(직접 참조)를 얻을 수 있다.

Vtable 과 상속

클래스를 상속한 뒤, 오버라이딩 하지 않은 메서드를 호출하면 부모 클래스의 메서드가 호출된다.

Vtable 을 만들때는 부모 클래스의 Vtable 을 복사하여 만든다. 오버라이딩하지 않는다면 하위 클래스 vtable 주소 항목은 부모 클래스 vtable 주소 항목과 같다. 하위 클래스에서 오버라이딩을 했을 때 하위 클래스의 vtable 의 주소값이 오버라이딩 메서드 시작점으로 바뀐다.

반대로 말하면 vtable 에 부모 메서드의 주소가 있다면 오버라이딩되지 않았다고 볼 수 있다.

https://blog.csdn.net/weixin_36274355/article/details/114353090

Object 는 모든 클래스의 부모다. Father 과 Son 은 Object 의 메서드를 오버라이딩 하지 않았기 때문에 Object 의 메서드를 가리키게 되고, hardChoice 는 Father 과 Son 둘 다 오버라이딩 했기 때문에 각자의 메서드 주소를 가리키는 그림이다.

출처

예제 코드 출처 https://github.com/WegraLee/JVM

메서드는 JVM 의 기본 실행 단위이다. 하나의 메서드가 실행될 때 JVM 은 내부적으로 스택 프레임 이라는 데이터 구조를 사용한다. 하나의 스택 프레임 내부에는 하나의 메서드를 실행시키기 위한 데이터들이 저장된다.

컴파일 시점에 지역 변수 테이블과 피연산자 스택이 필요로하는 슬롯 개수 가 정해지고, JVM 스택 메모리 레이아웃에 따라 슬롯 하나의 비트수 가 정해진다. 런타임에는 메서드가 필요로 하는 메모리 크기가 변하지 않는다는 말이다.

지역 변수 테이블

메서드 실행시 메서드 매개변수와 지역변수를 저장한다. 메서드의 행동을 정의하는 바이트코드 명령어는 이 곳의 값을 load 하여 피연산자 스택으로 옮겨가 사용한다.

크기는 클래스 파일 메서드 테이블에 Code 속성의 max_locals 에 슬롯 수가 적혀있다. 슬롯의 크기는 32bit 시스템에서는 32bit, 64bit 시스템에서는 64bit 이다.

32bit 데이터 boolean, byte, char, short, int, float, 참조 타입(compressed oops) 의 경우 슬롯 하나에 저장된다. long, double 의 경우 32bit 시스템에서는 두개의 슬롯에 나눠 저장한다. 이 두 슬롯은 무조건 같이 읽히며, 하나의 슬롯만 접근하는 명령어는 클래스 로딩 검증 시점에 차단된다.

this 는 암묵적인 매개변수이다. 따라서 지역 변수 테이블에 저장되는 데이터는 다음과 같다.

1. this
2. 매개 변수들
3. 지역 변수들

지역 변수 슬롯 재사용 및 코딩 팁

지역 변수는 메서드 내에서도 유효한 범위가 정해져 있다. JVM 은 공간을 절약하기 위해 지역변수 슬롯을 재사용한다. 유효범위가 끝난 지역변수 자리에 새로운 지역 변수를 저장한다.

하지만 이런 지역 변수 슬롯 재사용은 잘 알고 사용해야 한다.

//-verbose:gc
public class SlotReuse {
    public static void main(String[] args) {
        {
            byte[] placeHolder = new byte[64 * 1024 * 1024];
        }
        // int a = 0;
        System.gc();
    }
}

위 코드에서 placeHolder 지역 변수의 유효 범위는 {} 블록이 끝나면 끝난다. 만약 JVM 이 유효 범위가 끝난 지역 변수의 슬롯을 재사용하기 위해 비운다면, gc() 를 호출했을때 가비지 컬렉팅이 되어야 할 것 같다. 하지만 로그를 보면 여전히 메모리를 차지한다.

이는 변수 슬롯에 여전히 바이트 배열의 참조가 있고, 유효한 GC Root 라는 뜻이다.

placeHolder 가 gc 되기 위해서는 주석친 코드를 해제하면 된다. 이로 재사용의 메커니즘을 할 수 있다. 유효 범위가 끝난 placeHolder 가 있던 슬롯에 a 변수값이 들어가게 되고 더이상 스택 프레임에는 placeHolder 가 없으므로 GC Root 가 아니게 되어 GC 되는 것이다.

과거에는 이 슬롯 재사용을 활용하기 위해 위 int a = 0 같은 의미없는 코드를 권유하기도 했지만,

그 이전에 지역 변수 범위에 맞게 메서드 자체를 나누는게 더 우아한 해결책이다.

피연산자 스택

피연산자 스택(operand stack) 은 바이트 코드 명령어가 연산을 실행할 때 사용하는 공간이다.

예를 들어 iadd 는 피연산자 스택의 가장 위 두 슬롯의 숫자를 pop 하여 더한 후 다시 피연산자 스택에 push 한다.

피연산자 스택의 크기 역시 지역 변수 테이블 처럼 컴파일 시점에 계산되어 정해진다. 클래스 파일에 Code 속성의 max_stacks 값으로 명시되어 있다.

HotSpot 에서 피연산자 스택 최적화

class A {
    public int sum(int a, int b){
        return a+b;
    }
}

class B {
    public int calculate(){
        A a = new A();

        int sum = a.sum(10, 20); // (1)
        return sum * 3;
    }
}

public static void main(String[] args) {
    B b = new B();
    int result = b.calculate();
    System.out.println(result);
}

B 메서드에서 매개 변수가 있는 A 의 메서드를 호출하는 순간(1)에는 피연산자 스택 최상위에는 다음과 같은 데이터가 들어있다.

1. Callee(B) 의 객체
   • 매서드 인자에 암묵적으로 들어가는 메서드의 객체다. 메서드 내에서 this 로 쓰인다.
   • 위 예시 코드에서는 A 객체
   • 바이트 코드상 aload_n 으로 표시
2. Callee 인자 1
   • 위 예시 코드에서는 10
3. Callee 인자 2
   • 위 예시 코드에서는 20

이 피연산자 스택 최상위 데이터는 B 메서드로 호출이 넘어갔을때에는 매개 변수로서 지역 변수 테이블에 저장된다.

피연산자 스택이든 지역 변수 테이블이든 메모리상의 데이터이므로 이 두 구조를 복사해서 만들기보단 그대로 재사용한다면 좋을 것이다.

실제로 HotSpot 을 포함한 여러 JVM 에서는 이를 재사용하는 최적화가 존재한다.

동적 링크

이는 상수 풀에 대한 참조이다. 다른 글에서 자세히 서술할 예정

반환 주소

invoke~ 바이트 명령어가 실행되면 새로운 스택 프레임을 만들면서 메서드가 호출된다. 이 때 새로운 스택 프레임에는 반환 주소 가 저장된다.

정확하게는 다음 2가지 정보가 저장된다.

1. 돌아와야할 스택 프레임의 위치
2. 돌아와야할 PC Counter(명령어) 주소

만약 호출이 끝나고 return, ireturn, areturn 등 반환 명령어를 만난다면, 다음 세가지를 진행함으로서 호출했던 메서드로 돌아간다.

1. 반환 주소 를 보고 이전의 스택 프레임으로 귀환
2. 기존의 피연산자 스택과 지역 변수 테이블 복원
3. 반환값을 피연산자 스택에 쌓음

https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-2.html

반면, 위의 경우는 정상적으로 메서드 호출이 끝났을 때이다. 메서드가 종료되는 경우는 예외가 터졌을때도 있다.

이 때에도 마찬가지로 현재 활성화된 스택 프레임을 종료하고 이전 스택 프레임으로 이동하는건 같다. 하지만 PC Counter 로 이동하는것이 아닌 예외 테이블(Exception Table) 을 기준으로 동작한다. 적절한 예외 처리 handler 가 나올 때 까지 스택 프레임을 pop 하면서 찾는다.

클래스 로딩 단계 중 첫번째 로딩 단계 중 완전한 이름을 보고 해당 클래스를 정의하는 바이너리 바이트 스트림 가져오기 는 ClassLoader 라는 JVM 외부 컴포넌트에서 이뤄진다.

이는 JVM 설계 의도이다. JVM 설계자들은 이 행동이 외부에서 이뤄져서 JVM 과 독립적으로 다양하게 사용자가 사용할 수 있도록 의도되었다.

클래스 로더의 독립성

클래스 로더가 로딩한 클래스는 클래스 로더 별로 독립적인 네임 스페이스를 가진다. 따라서 같은 클래스라 하더라도 다른 클래스 로더가 로딩하면 동등성 비교가 false 이다.

따라서 동등성을 사용하는 equals(), isAssignableFrom(), instanceOf 등의 구문들에 영향을 끼칠 수 있다.

클래스 로더의 부모 위임 모델

JDK 8 까지 클래스 로더는 3계층 부모 위임 클래스 로딩 아키텍처 를 사용했다. JDK 9 이후에는 모듈 추가에 의해 조금 변형되었지만 큰 틀은 비슷하다.

클래스 로더 종류

1. 부트스트랩 클래스 로더
   • 로드하는 것
     • rt.jar, tools.jar 같은 JVM 이 클래스 라이브러리로 인식하는 파일
     • JAVA_HOME/lib 경로의 파일
     • -xbootclasspath 설정위치 파일
   • 가장 기본적인 JDK 클래스들을 로드하는게 이 부트스트랩 클래스 로더이다.
   • 부트스트랩 클래스 로더는 자바에서 직접 참조할 수 없다. C++ 로 구현되어 있다. 만약 커스텀 클래스 로더에서 부트스트랩 클래스 로더로 작업을 위임하고 싶다면, 클래스 로더 참조 자리에 null 을 넣어야 한다.

rt.jar 에는 java.lang, java.io 등이 들어있다.

2. 확장 클래스 로더
   • sun.misc.Launcher$ExtClassLoader
   • 로드하는 것
     • JAVA_HOME/lib/ext 경로의 파일
     • java.ext.dirs 시스템 변수값 위치의 파일
   • 사용자가 위의 위치에 범용 라이브러리 클래스 파일을 넣어 SE 기능을 확장하여 사용

3. 애플리케이션 클래스 로더
   • sun.misc.Launcher$AppClassLoader
   • 로드하는 것
     • 클래스 패스상의 클래스 라이브러리들
   • ClassLoader.getSystemClassLoader(); 의 결과가 이 클래스 로더
   • 따로 클래스 로더를 만들지 않으면, 애플리케이션에서 실행에 기본적으로 사용되는 클래스 로더

클래스 패스 : 애플리케이션 클래스 로더가 로딩할 클래스 파일들의 위치

위임 모델

클래스 로더가 로딩 요청을 받으면, 먼저 상위 클래스 로더에 위임하여 상위 클래스 로더에서 로딩을 시도한다.

만약 상위 클래스 로더의 로딩 대상이 아니라면 그제서야 하위 클래스로더로 넘어간다.

따라서 어느 클래스 로더를 사용하든 가장 먼저 부트스트랩 클래스 로더로 로딩을 시도한다.

이 구조는 공통적인 클래스는 같은 클래스 로더가 생성함을 보장한다. 예를 들어 공통적으로 사용하는 java.lang.Object 의 경우 어떤 커스텀 클래스 로더에 의해 로드하더라도 하나의 Object 클래스가 생성되는게 맞다. 계층구조 위임 모델은 이를 보장한다.

계층 구조 위임 모델의 구현은 상속보다는 컴포지션을 사용한다. 커스텀 클래스 로더를 만들 일이 있으면 참고하자.

커스텀 클래스 로더

추상 클래스인 java.lang.ClassLoader 를 상속하여 구현하면 된다.

커스텀 클래스 로더를 만들때 핵심적인 두 메서드가 있다.

• loadClass()
• findClass()

커스텀 클래스 로더를 만들 때에는 findClass() 만 오버라이딩하면 된다.

java.lang.ClassLoader 은 이미 컴포지션, 위임 개념이 들어간 loadClass() 를 구현하고 있다. loadClass() 안에서 실질적으로 클래스 파일을 얻는 부분은 findClass() 이다.

부모 위임 모델과 컴포지션을 그대로 사용하면서 커스텀 클래스 로더를 만드려면 findClass() 만 오버라이딩하면 된다.

Thread Context 클래스 로더

자바의 모든 스레드는 기본적으로 TCCL 이라 부르는 클래스 로더를 가지고 있다. Thread.currentThread().getContextClassLoader(); 를 실행해 보면 해당 클래스 로더를 볼 수 있다. 기본적으로 AppClassLoader 가 들어간다.

이런 설계의 원인은 다음과 같다.

JNDI 는 rt.jar 의 일부로서 부트스트랩 클래스 로더가 로드한다. 하지만 JNDI 는 사용자가 설정한 설정 클래스를 읽어야 한다. 부모 위임 모델에서는 상위 클래스 로더인 부트스트랩 클래스 로더가 애플리케이션 클래스를 볼 수 없다.

따라서 스레드는 주머니에 하위 클래스 로더를 따로 하나씩 들고 다니다가 필요시에 사용하도록 했다. 이것이 TCCL(Thread Context Class Loader) 이다.

JDBC, JCE, JAXB 등 SPI 서비스 관련 로딩은 모두 이 방식을 사용한다.

들어간 원인은 이 때문인데, spring 이든 여기저기서 스레드에서 클래스 로더 꺼내서 잘 활용하는듯 하다. 막 어디서 찾을 필요 없이 스레드에서 바로 꺼낼 수 있으니..

JDK 9 (모듈) 이후 클래스 로더

https://docs.oracle.com/en/java/javase/21/migrate/migrating-jdk-8-later-jdk-releases.html#GUID-A868D0B9-026F-4D46-B979-901834343F9E

JDK 9 에는 jdk 의 왠만한 클래스를 모두 포함하는 rt.jar 가 사라지고, 내부에 있던 많은 패키지들은 각각 모듈로 바뀌었다.

이에 따라 ClassLoader 계층구조에도 몇가지 변화점이 생겼다.

• 계층구조 자체는 유지.
• ExtClassLoader -> PlatformClassLoader 로 변경
• 부트스트랩, 플랫폼, 애플리케이션 클래스 로더가 jdk.internal.loader.BuiltinClassLoader 로부터 파생되도록 변경(기존에는 URLClassLoader)
• 클래스 로더가 부모에게 위임하기 전, 로딩할 클래스가 특정 모듈에 속하는지 확인하고 그렇다면 해당 모듈의 클래스 로더로 위임하는 과정 추가.

[rt.jar 가 모듈로 쪼개짐] JAVA_HOME/jmods 에는 컴파일용 jmod 파일들이, JAVA_HOME/lib/modules 파일에는 런타임용 모듈들이 정의되어 있음. 내용물은 같음. jimage extract $JAVA_HOME/lib/modules 명령어로 extract 가능

[ExtClassLoader 의 삭제] 모듈화가 되면서, 기존에 모든 커스텀 클래스 로더를 확장할 용도로 쓰이던 ExtClassLoader 가 필요 없어졌다.

확장할 기능을 모듈로 만든 뒤 의존성을 정해주는 방식으로 확장하게 권장한다. 다만 gradle/maven 의 의존성 관리가 좀 더 많이 쓰이는듯..

[PlatFormClassLoader 가 굳이 필요한가? BootstrapClassLoader 로 통합했으면 안되었나?] platform 클래스 로더는 말 그대로 플랫폼 클래스들을 로딩하기 위해 사용한다. 실제로는 java.lang 은 BootstrapClassLoader, java.sql 은 PlatformClassLoader 처럼 클래스 로더가 로딩하는 모듈이 나뉘어 있다.

하지만 위임 모델로 PlatformClassLoader 를 통해 BootStrapClassLoader 가 담당하는 클래스도 모두 로딩할 수 있으며 사용자 입장에서 Bootstrap/Platform 각각이 어떤 클래스를 로딩하는지의 구분을 알 필요는 없다.

다만 BootStrapClassLoader 는 C++ 로 짜여져서 코드상 직접 사용할 수 없다. 그렇다고 AppClassLoader 는 애플리케이션용이라 이 클래스로 플랫폼 클래스들을 로딩하는건 부자연스럽다. 따라서 java.lang, java.sql 등 플랫폼 클래스 로딩을 제어를 자바 코드에서 하기 위해 만든 클래스 로더 계층이라 할 수 있다.

public static void main(String[] args) throws ClassNotFoundException {
    ClassLoader cl = ClassLoader.getPlatformClassLoader();

    Class<?> c1 = cl.loadClass("java.lang.String"); // BootStrapClassLoader 로 위임
    Class<?> c2 = cl.loadClass("java.sql.Date"); // PlatformClassLoader

    System.out.println(c1.getName());
    System.out.println(c2.getName());
}

Spring Boot, Tomcat 의 클래스 로더

Tomcat Class Loader

WebappClassLoader 는 톰켓에 올라갈 수 있는 여러개의 애플리케이션 각각에서 사용되는 클래스로더다. 예를 들어 war 3개를 올려놨다면 3개의 WebappClassLoader 가 사용되는 것이다.

WebappClassloader 는 /WEB-INF 경로의 애플리케이션 파일과 의존 라이브러리 jar 를 로드하는 역할이다. (war 파일 형식의 /WEB-INF 를 보자)

WebappClassLoader 의 상위 클래스로더인 Common 클래스 로더가 있다. 이는 lib 디렉토리(Tomcat 6 부터)를 클래스패스로 하는 클래스로더이며, 여러 애플리케이션이 공통으로 사용한다.

Spring Boot Class Loader

spring boot 는 임베디드 톰켓을 사용한다. spring boot 의 bootjar 는 독립적으로 실행 가능한 jar 로서, 내부에 애플리케이션 클래스 파일과 의존 라이브러리 jar 를 가지고 있다.

즉, bootjar 는 nested jar 이다.

문제

Tomcat 의 기본적인 WebappClassLoader 는 클래스 로딩시 SystemClassLoader(보통 AppClassLoader) 를 사용할 수 있다. (WebappClassLoader 의 생성자를 보면 parent = null 시 SystemClassLoader 사용)

하지만 SystemClassLoader 는 의존 라이브러리들인 중첩된 jar 를 읽을 수 없다. 따라서 따로 중첩 jar 를 읽을 수 있는 클래스로더 메커니즘을 제공해야한다.

해결

spring boot 는 spring-boot-loader 에 정의된 LaunchedClassLoader 를 사용한다.

이 클래스 로더는 JarURLClassLoader 로서, 중첩된 Jar 를 해석할 수 있게 구현되어 있다.

그렇다면 WebappClassLoader 부모로서 LaunchedClassLoader 를 가지게 하면 될까? 아니다. WebappClassLoader 는 때때로 SystemClassLoader 를 사용할 수 있다 했다. spring boot 에서는 SystemClassLoader 가 아닌 LaunchedClassLoader 를 사용해야한다. 이 로직이 들어간 것이 TomcatEmbeddedWebappClassLoader 이다.

즉 TomcatEmbeddedWebappClassLoader 는 spring boot 에서 온전히(SystemClassLoader 관여 없이) 부모 클래스 로더인 LaunchedClassLoader 만 사용되도록 하는 구현을 가지고 있다.

결론

스프링 부트에서는 TCCL(Thread Context Class Loader) 로 TomcatEmbeddedWebappClassLoader 를 가지고 다니면서 Nested Jar 구조에서 정상적으로 클래스 로딩이 가능하다.

intellij 같은 IDE 에서는 외부 의존성 jar 에 대한 class path 를 IDE 가 자동으로 지정해주므로 System ClassLoader(AppClassLoader) 로 의존성 라이브러리 클래스를 로드할 수 있다. IDE 와 BootJar 에서 스프링 부트를 실행시키는 방법이 다름에서 오는 차이다.

참고

이 내용은 spring boot docs 에서도 엿볼 수 있다.

Thread.getContextClassLoader() 로 얻은 클래스 로더를 사용하라는 것이다. ClassLoader.getSystemClassLoader() 로 얻은 클래스 로더를 사용하면 실패한다.

다음 코드를 spring boot 에서 bootJar 로 구동하여 실행해보자. logback 라이브러리 클래스를 로드하는 코드인데, ClassLoader.getSystemClassLoader() 클래스 로더로 실행시 실패한다.

val threadClassLoader = Thread.currentThread().contextClassLoader
println(threadClassLoader.loadClass("ch.qos.logback.core.hook.DefaultShutdownHook")) // 이건 성공
println("thread = $threadClassLoader")

val systemClassLoader = ClassLoader.getSystemClassLoader()
println(systemClassLoader.loadClass("ch.qos.logback.core.hook.DefaultShutdownHook")) // 여기서 실패
println("system = $systemClassLoader")

반면 IDE 에서 실행할 경우에는 둘 다 성공한다.

다음은 Thread.getContextClassLoader() 클래스 로더의 toString() 값이다. 부모 클래스 로더로 LaunchedClassLoader 를 가지고 있음을 알 수 있다.

thread = TomcatEmbeddedWebappClassLoader
  context: ROOT
  delegate: true
----------> Parent Classloader:
org.springframework.boot.loader.launch.LaunchedClassLoader@28a418fc

참고 2 - java.util.logging

JDK 에는 로깅관련 라이브러리가 기본적으로 있다. 하지만 spring boot 를 사용할때면 logback, log4j2 등 로깅 라이브러리를 따로 사용한다.

이는 클래스 로더 문제와 관련있다.

java.util.logging 이 가진 문제가 System ClassLoader 가 아니면 클래스 로딩이 재대로 안된다. 따라서 nested jar 구조에서는 사용할 수 없다.

반면 자바는 컴파일시 심벌 참조만 가진 클래스 파일을 만든다. JVM 런타임에 이 심벌 참조는 직접 참조로 바뀌어 실제 메모리 주소값을 가진 호출을 가지게 된다.

이 구조는 인터페이스와 구현체들을 만들어 놓고 실제 사용할 구현체를 런타임에 결정하거나, 클래스로더를 사용하여 런타임에 실행할 바이너리 스트림을 동적으로 외부에서 읽어오는 등 정적인 언어가 동적인 언어로 확장될 수 있는 기반이 된다.

반면 런타임에 하는 일이 많아지므로 살짝의 느림과 AOT 에 제약이 걸리긴 한다.

클래스 로딩

[_JVM 밑바닥까지 파헤치기_]

JVM 에서 클래스 로딩은 위와 같은 단계를 거친다.

단계들의 실행시간이 겹쳐 병렬로 실행되는것 처럼 보일 수 있지만, 시작 시간은 반드시 위와 같은 순서로 시작되어야 한다.

클래스 로딩 시작

자바 가상 머신 명세에는 가장 첫 단계인 로딩 이 언제 시작해야하는지는 명시가 없다. 다만, 초기화 단계는 언제 시작되어야 하는지 명시가 되어 있다. 아래의 6가지 경우 초기화 가 진행되어야 하며 이것이 로딩 부터 시작하여 클래스 로딩이 시작되는 트리거다.

1. 다음 바이트 코드 명령어 실행시 대상의 타입이 초기화 되어있지 않을 때.
   • new : 새 객체 인스턴스 생성
   • getstatic, putstatic : 정적 필드를 읽거나 설정(final 지정된 정적 필드는 컴파일 타임에 상수 풀에 채워지므로 제외)
   • invokestatic : 정적 메서드 호출
2. Class 클래스, 리플랙션 패키지 등 표준 클래스 라이브러리에서 제공하는 리플렉션 메서드를 사용할 때 해당 타입이 아직 초기화 되어 있지 않은 경우
3. 클래스를 초기화할 때 상위 클래스가 초기화 되어 있지 않은 경우
4. 가상 머신은 구동 직후 사용자가 정한 main() 을 찾아 실행함. 이 때 main 타입의 초기화 먼저 시작
5. REF_getStatic, REF_putStatic, REF_invokeStatic, REF_newInvokeSpecial 타입 메서드 핸들을 해석해 얻은 MethodHandle 인스턴스를 호출할 때 해당하는 클래스가 초기화되어 있지 않은 경우
   • MethodHandle 은 동적 언어 지원 메서드.
   • 쉽게 말하면 MethodHandle 의 invokeExact 메서드 실행 시 초기화 된다는 것.
6. 인터페이스에 디폴트 메서드가 있다면, 해당 인터페이스의 구현한 클래스가 초기화될 때 인터페이스도 초기화

위의 6가지 경우는 모든 가상 머신에서 클래스 로딩 및 초기화가 시작된다. 나머지 경우는 타입에 대한 수동 참조로서 클래스 로딩이 진행될지는 JVM 구현에 따라 다르다.

클래스 로딩이 될 것 같은데 안되는 예시

상위 클래스의 상수를 하위 클래스를 통해 실행하면, 하위 클래스의 초기화는 안된다. 아래의 결과는 상위 클래스 초기화! 다. 하위 클래스를 통해 호출했지만 하위 클래스의 초기화는 되지 않는다.

이 때 로딩과 링킹은 진행할지 말지 자유인데, 핫스팟 VM 의 경우 -Xlog:class+load=info ㄸ또는-XX:+TraceClassLoading 으로 보면 하위 클래스(SubClass) 의 로딩까진 진행하는 것을 볼 수 있다.

class SuperClass {
    static {
        System.out.println("상위 클래스 초기화!");
    }

    public static int value = 123;
}

class SubClass extends SuperClass {
    static {
        System.out.println("하위 클래스 초기화!");
    }
}

public class NotInitialization_1 {
    public static void main(String[] args) {
        System.out.println(SubClass.value);
    }
}

아래의 경우 SuperClass, SubClass 모두 초기화되지 않는다. 다만 [L 이 붙은 컴파일러가 만든 클래스가 초기화가 된다. (anewarray 바이트코드 명령에 의해) 이는 배열에 대한 length, clone() 속성 및 메서드를 구현하는 클래스이다.

public class NotInitialization_1 {
    public static void main(String[] args) {
        SuperClass[] sca = new SuperClass[10];
    }
}

아래 역시 ConstantClass 초기화! 가 불리지 않는다. 컴파일 타임에 ConstClass.HELLO_WORLD 가 최적화 되어 NotInitialization_3 의 상수 풀에 들어간다. 이는 javap 를 사용하면 볼 수 있다.

class ConstClass {
    static {
        System.out.println("ConstClass 초기화!");
    }

    public static final String HELLO_WORLD = "hello world";
}

public class NotInitialization_3 {
    public static void main(String[] args) {
        System.out.println(ConstClass.HELLO_WORLD);
    }
}

클래스 로딩 과정

로딩 -> 검증 -> 준비 -> 해석 -> 초기화

1. 로딩

• 완전한 이름을 보고 해당 클래스를 정의하는 바이너리 바이트 스트림 가져오기
• 바이스 스트림(정적인 저장 구조)을 메서드 영역에서 사용하는 런타임 데이터 구조로 변환
• java.lang.Class 객체를 힙에 생성. 사용자는 이를 통해 메서드 영역 데이터 활용.

ClassLoader 의 findClass(), loadClass() 메서드가 해당 단계이다. 이 메서드를 조절하면 로딩 단계를 커스텀할 수 있다.

로딩 단계에서 검증 단계의 일부(파일 형식 검증) 이 실행될 수 있다.

2. 검증 (링킹 - 1)

바이트 스트림은 자바 코드를 컴파일한 클래스 파일 외에도 여러 경로로 만들어질 수 있다. 따라서 자바 컴파일러 외에 JVM 에서 공통적으로 검증 과정이 있어야 한다.

목적은 다음과 같다.

• 자바 가상 머신 명세의 제약들을 다 지켰는지
• 실행했을때 보안상의 위협이 없는지

검증은 4가지 항목에 대해 이뤄진다.

1. 파일 형식 검증
2. 메타데이터 검증
3. 바이트 코드 검증
4. 심벌 참조 검증

검증 단계는 필수는 아니다. 따라서 오래 걸리는 검증 단계를 생략함으로 코드 실행 시간을 단축 할 수 있다. (-Xverify:none) 만.. 그럴 수 있을까.

파일 형식 검증

파일 형식 검증은 로딩 단계에 같이 진행된다. 파일 형식 검증은 바이트 스트림을 대상으로 진행한다.

로딩과 파일 형식 검증이 끝나면 메서드 영역에 저장이 끝난다. 따라서 이후 메타데이터, 바이트 코드, 심벌 참조 검증은 메서드 영역에 대해 진행된다.

• 매직 넘버 0xCAFEBABE 인지
• 메이저, 마이너 버전이 자바 허용 범위인지
• 상수 풀에 지원하지 않는 타입이 있는지
• 상수 풀 인덱스 중 유효하지 않은게 있는지
• CONSTANT_Utf8_info 타입에 UTF-8 인코딩 아닌게 있는지

등등..

메타데이터 검증

자바 가상 머신 명세의 요구 사항 검사.

• 부모 클래스가 있는가? (모든 클래스의 상위는 Object)
• 부모 클래스에 final 이 없는가?
• 추상 클래스를 구현한 경우 모든 추상 메서드를 구현했는가?

등등..

바이트 코드 검증

데이터 흐름과 제어 흐름을 분석하여 프로그램의 의미가 적법하고 논리적인지 확인. 메서드 본문(클래스 파일의 Code 속성) 을 대상으로 검증한다.

• 피연산자 스택 데이터가 int 라면 명령어에 의해 지역 변수 테이블에 저장되는 데이터도 int 여야 함.
• 점프 명령어가 이상한 곳 가면 안됨
• 안전하지 않은 형 변환이 있는지 확인

등등..

이 단계는 검증할게 너무 많다. 느림의 주된 원인이 될 수 있다. 클래스 파일의 stackMapTable 속성은 일부 바이트 코드 검증 단계에서 할 작업을 컴파일 단계로 넘김으로 느린 문제를 해결한다.

분기, 점프, 예외 핸들러는 여러 케이스가 한 지점으로 모이는 구문들이다. 이 때의 피연산자 스택과 지역 변수 테이블에 저장된 데이터의 타입을 컴파일 시점에 명시적으로 저장해두고, 바이트 코드 검증 시점에는 해당 타입이 유효한지만 확인하면 된다.

이게 있기 전에는 바이트 코드 검증 단계에서 피연산자 스택과 지역 변수 테이블에 저장된 데이터의 타입을 추론해야 했기에 느렸다.

심벌 참조 검증

링킹의 세번째인 해석 단계에서 심벌 참조가 직접 참조로 변환될 때 실행하는 검증. 현재 클래스가 참조하는 외부 클래스, 메서드, 필드 등에 접근할 권한이 있는지 확인.

• 심벌 참조에서 리터럴로 기술된 클래스를 실제로 찾을 수 있는가?
• 서술자에 적힌 메서드나 필드가 실제로 클래스에 존재하는가?
• 접근 지정자가 접근을 허용하는가?

여기서 NoSuchFieldError, NoSuchMethodError 등 IncompatibleClassChangeError 하위를 던진다.

3. 준비 (링킹 - 2)

클래스 변수(정적 변수)를 메모리에 할당 및 초깃값 설정

또한 코드에서 지정한 초기값이 아닌 0 등 기본값으로 초기화된다.

숫자형은 0, boolean 은 false, 객체는 null 로 초기화.

기본값으로 채워지지 않는 예외의 경우가 있는데, ConstantValue(클래스 파일 중 필드 테이블의 속성) 이 만들어지는 final static String 과 primitive type 의 경우에는 이 단계에서 ConstantValue 값이 초기화된다.

4. 해석 (링킹 - 3)

심벌 참조를 직접 참조로 변환한다.

심벌 참조를 다루는 바이트 코드 명령어 (anewarray, checkcast, getfield, getstatic, instanceof, invokedynamic, invokeinterface, invokespecial, invokestatic, invokevirtual, ldc, ldc_w, ldc2_w, multianewarray, new, putfield, putstatic) 가 사용하는 심벌 참조를 나타내는 상수 풀의 CONSTANT_Class_info, CONSTANT_Fieldref_info, CONSTANT_Methodref_info, CONSTANT_InterfaceMethodref_info, CONSTANT_MethodType_info, CONSTANT_MethodHandle_info, CONSTANT_Dynamic_info, CONSTANT_InvokeDynamic_info 를 직접 참조로 변환한다.

동적으로 결과가 바뀌는 invokedynamic 을 제외한 명령어들은 여러번 해석해도 항상 같은 결과가 나와야 한다. 따라서 한번 해석한 심벌 참조의 경우 상수 풀에 해석되었다고 표시하는 캐싱이 이뤄진다.

해석을 클래스 로딩 시점에 할 것인지, 실제 사용될 때 할 것인지는 JVM 구현에 달려있다.

이 단계는 리터럴 심벌 참조를 실제 주소인 직접 참조로 바꾸는 과정이기 때문에, 다른 클래스의 연쇄적인 클래스 로딩을 유발할 수 있다.

5. 초기화

클래스 생성자 <clinit>() 을 실행한다. <clinit>() 는 컴파일러가 자동 생성한다. 클래스 변수를 프로그램에 작성한 대로 초기화하고, 정적 블록(static {})을 실행한다.

<clinit>() 은 부모 클래스가 있다면 먼저 실행한다. 따라서 자바에서 가장 먼저 실행되는 클래스 생성자는 Object 의 <clinit>() 이다.

반면 인터페이스(정적 변수 가능)는 실제 사용될 때 <clinit>() 가 실행된다. 즉, 구현 클래스의 <clinit>() 가 불리더라도 인터페이스의 <clinit>() 는 불릴 필요 없다.

정적 블록이나 정적 변수가 없다면 <clinit>() 가 존재하지 않을 수도 있다.

정적 블록은 멀티 스레드 문제에 민감하다. n개 스레드가 한 클래스를 동시에 로딩할 수 있다. 만약 정적 블록에 오래 걸리는 일이 있다면, n-1 개의 스레드는 블로킹 대기하게 된다.

바이트 코드 명령어

• 클래스 파일에 [바이트 코드 명령어] + [필요시 피연산자] 형태로 작성된다.
• 최대 256 개 표현 가능. u1 타입으로 정의되어 있기 때문.
• 피연산자 길이 정렬(length alignment) 를 지원하지 않는다. CPU 는 무조건 1byte 단위로만 읽는다는 이야기다.
  • JVM 의 철학(어느 환경이든 일관된 실행) - 1 byte 로만 해석
  • 예를 들어 16비트 double 은 메모리상 2 bytes 로 나눠 저장되고, jvm 이 (byte1 << 8) | byte2 와 같은 연산으로 계산해서 사용
  • 단점 : 이는 바이트 코드 해석 및 실행 속도를 약간 늦춘다.
  • 장점 : 패딩(공백)을 없앨 수 있고, 일관된 1byte 라 짧고 간결함. 최소 데이터로 전송 효율을 높이기 위한 자바 초기의 스마트 가전 시장에 적합했음

바이트 코드 명령어의 실행을 간단하게 표현하면 아래 4가지의 반복이다.

1. PC 레지스터의 값을 계산
2. 바이트 코드 스트림에서 PC 레지스터가 가리키는 위치의 바이트 코드 명령어 가져옴
3. 피연산자가 필요하다면 가져옴
4. 명령어 실행

특징

• 대다수 명령어는 앞에 타입을 나타내는 문자가 적혀있다. ex) iload(int load), fstore(float store), laload(long array load)

  • 타입을 구분하기 쉽게 하기 위한 설계

• 일부 명령어는 머신 내에서 타입 변환하여 쓰인다

  • ex) cload(char load) 같은건 없다. char 타입에 대한 load 는 iload 명령어로 동작한다.
  • byte, char, short 는 int 로 변환 가능하기에 이 타입 문자가 앞에 붙은 명령어는 거의 없다.
  • boolean 타입 문자가 앞에 붙은 명령어는 하나도 없다.
  • 256 개 안으로 명령어 수를 맞추기 위함이다.

  

  https://docs.oracle.com/javase/specs/jvms/se25/html/jvms-7.html

명령어

로드와 스토어

• 지역 변수를 피연산자 스택으로 읽기 : load
  • iload, ~iload_<n>, lload, ~lload_<n>, fload, ~fload_<n>, dload, ~dload_<n>, aload, ~aload_<n>
• 피연산자 스택의 값을 지역변수 테이블에 저장하기 : store
  • istore, istore_<n>, lstore, lstore_<n>, fstore, fstore_<n>, dstore, dstore_<n>, astore, astore_<n>
• 상수를 피연산자 스택으로 읽어오기
  • bipush, sipush, ldc, ldc_w, ldc2_w, aconst_null, icont_m1, icont_m1, lcont_<l>, fcont_<f>, dcont_<d>
• 더 넓은 인덱스를 사용하여 더 많은 지역 변수에 접근하거나 더 큰 피연산자에 접근하기
  • wide

_<n> 과 같이 써 있는 것들은 피연산자를 포함하고 있는 명령어들로, 자주 쓰이는 피연산자를 명령어에 합쳤다. 예를 들어 iload_0 은 iload 0 과 같다.

산술 명령어

피연산자 두개의 값으로 특정 산술 연산 후 결괏값을 다시 피연산자 스택의 맨 위에 저장한다. byte, short, char, boolean 은 직접 지원하는 산술 명령어가 없으며, int 명령어로 사용한다.

정수 연산의 오버플로는 명시가 없다 정수 나누기와 나머지 연산시 나누는 값이 0 이면 ArithmeticException 은 규정에 있다 이 외의 다른 정수 산술 시나리오에서는 런타임 예외를 던지지 않아야 한다.

IEEE754 - 부동 소수점 비정규화된 부동 소수점 수, 점진적 언더플로 지원해야함 모든 ㅇ녀산 결과를 적절한 정밀도로 반올림해야함 정확하지 않은 결과는 표현 가능한 가장 가까운 값으로 반올림 표현 가능한 두 값이 수학적으로 정확한 값과 차이가 똑같다면 최하위 비트가 0인 값을 우선시 -> 가까운 값으로 반올림 부동 소수점 수를 정수로 반환할 때는 0에 가까운 값으로 반올림(양수면 내림, 음수면 올림) -> 소수부의 모든 중요 바이트를 버림 - 대상 숫자 타입이 표현할 수 있는 숫자 중 정확한 값과 가장 가까우면서 더 크지 않은 값 선택해줌

부동 소수점 연산을 수행할 때 런타임 예외를 던지지 않는다. 연산이 오버플로 되면 부호있는 무한대로 표현 연산 결과에 대한 명확한 수학적 정의가 없다면 NaN

long 타입 비교시엔 부호 있는 비교 사용 jcmpg, dcmpl, fcmpg, fcmpl 등이 IEEE754 가 정의한 예외(시그널) 을 보내지 않는 비교

형 변환 명령어

숫자 타입 -> 다른 숫자 타입 코드에 명시한 형변환, char 등 전용 연산 코드가 없을때의 자동 현변환

데이터 타입의 표현 범위가 넓어지는 경우는 형 변환 명령어가 없어도 자동 처리됨 표현 범위가 줄어드는 경우 형 변환 명령어가 반드시 필요(i2b, i2c, i2s...)

큰 범위의 정수(int/long) -> 작은 단위의 정수(short/int/long)

• 초과하는 윗 부분의 비트가 버려진다.
• 이로 인해 부호가 바뀌거나, 값이 바뀔 수 있다. ex)(short) 65537 = 0, (short) 32768 = -1

부동 소수점 -> 정수 int/long

• 부동 소수점 값이 NaN 이면 -> 0 으로 변경
• 무한대가 아닌 수는 0과 가까운 값으로 반올림. 표현할 수 없다면 int/long 의 MIN/MAX

double -> float

• 기본적으로 가까운 값으로 반올림.
• 범위를 벗어나면 0/MIN/MAX
  • 절대값이 너무 작은 경우 음수0 또는 양수0 이 될 수 있다.

객체 생성과 접근 명령어

1. 클래스 인스턴스 생성 :new
2. 배열 생성 : newarray, anewarray, multianewarray
3. 인스턴스 필드 접근 : getfield, putfield
4. 클래스 필드 접근 : getstatic, putstatic
5. 배열의 원소를 피연산자 스택으로 읽어 오기 : baload, caload, saload, iaload, laload...
6. 피연산자 스택의 값을 배열의 원소에 저장 : bastore, castore ...
7. 배열의 길이 얻기 : arraylength
8. 클래스 인스턴스의 타입 확인 : instanceof
9. 배열의 타입 확인 : checkcast

피연산자 스택 관리

1. 피연산자 스택에서 최상위 원소 한개/두개 꺼내기 : pop, pop2
2. 스택의 최상위 값 한개/두개 복제 후 복제된 값을 스택 최상위에 다시 넣기 : dup, dup2, dup_x1, dup2_x1, dup_x2, dup2_x2
3. 스택 최상위 값 두개 치환 : swap

제어 전이 명령어

PC 레지스터 값을 조건적으로 또는 무조건 적으로 다른 명령어로 변환하는 명령어다. 변경 대상 명령어는 제어 전이 명령어가 아니어야 한다.

1. 조건 분기 : ifeq, iflt, ifle, ifgt, ifnull, if_icmpeq, if_icmplt, if_acmpeq, if_acmpne...
   • 스택의 두 값을 대상으로 비교 연산을 실행 후 결과에 따라 특정 라인으로 이동
   • 비교 연산은 산술 연산과 일관되게 byte, short, char, boolean 은 int 형 명령어로 사용
   • if_acmpeq(a 가 붙은 명령어) 는 참조타입용
2. 복합 조건 분기 : tableswitch, lookupswitch
3. 무조건 분기 : goto, goto_w, jsr, jsr_w, ret

jsr_w : jump to subroutine wide ret : return from subroutine

메서드 호출과 반환 명령어

1. invokevirtual : 인스턴스 메서드 호출. 객체의 실제 타입에 따라 디스패치.
2. invokeinterface : 인터페이스 메서드 호출. 런타임에 인터페이스 구현 객체의 메서드를 찾아 호출.
3. invokespecial : 인스턴스 초기화 메서드, private 메서드, 부모 클래스의 메서드 등
4. invokestatic : static 메서드
5. invokedynamic : 런타임에 callsite 한정자가 참조하는 메서드를 동적으로 찾아 호출. 앞의 네 명령어의 디스패치 로직은 사용자가 변경할 수 없지만, invokedynamic 의 디스패치 로직은 jvm 실행 시 사용자가 설정할 수 있다.

invokedynamic

호출 대상 결정을 런타임으로 미룬다. 대표적인 예로 람다가 있다. 람다는 컴파일시 invokedynamic 명령어 실행으로 나온다. 호출 대상 클래스가 정해져 있지 않다. 람다의 첫 호출시 컴파일때 정해진 방법으로 BootStrapMethod 를 호출한다. 이 때 어떤 메서드를 실행할지 결정하고 만든다. 따라서 첫 호출시에는 느릴 수 있다. 이후 호출시에는 callsite 라 불리는 미리 기억된 경로로 BSM 에서 생성된 메서드를 빠르게 실행한다.

1. 바이트코드에서 invokedynamic 만남
2. Bootstrap Method(BSM) 호출 (딱 한 번)
3. BSM이 CallSite 반환
4. CallSite 안의 MethodHandle 이 실제 호출 대상
5. 이후 호출은 직접 jump (거의 invokestatic 급)

dynamicinvoke 동적 언어를 정적 언어 처럼 최적화 가능

public class InvokedynamicTest {

    static Runnable makeStatelessLambda() {
        return () -> System.out.println("no capture");
    }

    static Runnable makeStatusLambda(int x) {
        return () -> System.out.println("capture x = " + x);
    }

    public static void main(String[] args) {
        Runnable r1 = makeStatelessLambda();
        Runnable r2 = makeStatelessLambda();

        System.out.println(r1 == r2);
        System.out.println(System.identityHashCode(r1));
        System.out.println(System.identityHashCode(r2));

        Runnable r3 = makeStatusLambda(10);
        Runnable r4 = makeStatusLambda(10);

        System.out.println(r3 == r4);
        System.out.println(System.identityHashCode(r3));
        System.out.println(System.identityHashCode(r4));
    }
}

예외 처리 명령어

• 자바의 throw 구문으로 명시적 예외 발생시 athrow 바이트 코드 명령어가 사용됨

동기화 명령어

• synchronized 와 관련된 명령어
• synchronized 함수인지는 메서드 테이블의 ACC_SYNCHRONIZED 플래그를 보고 확인한다. ACC_SYNCHRONIZED 플래그가 켜진 함수에 진입시 바이트 코드 명령어 monitorenter 를 사용하여 락(모니터 라고도 함) 을 획득한다.
• monitorexit 은 락은 해제하는 명령어이다.
• jvm 은 자동으로 예외 처리 테이블을 만들어 줌으로서 반드시 monitorenter 에 대응되는 monitorexit 가 실행되도록 보장한다.

과거에는 리눅스, 윈도우 등 플랫폼에 독립적으로 아무 곳에서 작성해도 실행할 수 있는 것 이었지만, 이제는 언어 독립성도 생긴다. 코틀린, 자바, 스칼라 등 언어가 달라도 바이트 코드를 만들 수 있는 각각의 컴파일러가 있어서 JVM 에서 실행할 수 있는 코드를 언어 독립적으로 만들 수 있다.

이러한 것이 클래스 파일이라는게 있기 때문이며, 클래스 파일의 형태 및 규칙은 JDK1 부터 거의 바뀌지 않고 있다.

클래스 파일 구조

• 구분자가 없는 바이트 스트림. 따로 구분자가 없기에 데이터가 작성되는 순서, 의기, 길이 등이 엄격하게 지켜져야 한다.
• 1byte 단위로 작성
• 클래스 파일이 저장하는 데이터(순서대로)
  • 매직 넘버와 클래스 파일의 버전
  • 상수 풀
  • 접근 플래그
  • 클래스 인덱스, 부모 클래스 인덱스, 인터페이스 인덱스
  • 필드 테이블
  • 메서드 테이블
  • 속성 테이블
• 두가지 타입 존재
  • 부호 없는 숫자 : u1, u2, u4, u8 / 각각 1bytes 2bytes 4bytes 8bytes
  • 테이블 : 여러개의 부호 없는 숫자 또는 다른 테이블로 구성된 복합 데이터 타입. 관례적으로 테이블 이름에 '_info' 접미어가 붙는다.
• 같은 타입의 데이터 여러개를 표한할 때 수가 정해져 있지 않다면 개수를 알려주는 부호 없는 숫자 타입이 바로 앞에 등장한다. 이러한 데이터에는 '_count' 접미어가 붙는다.
• 클래스파일은 꼭 파일 형태로 있지만은 않다. 런타임에 동적으로 생성되어 클래스 로더에 제공되는 이진 스트림 집합체도 JVM 에 올라가는 클래스 파일일 수 있다.

다음은 클래스 파일을 테이블 형태로 나타낸 것. 클래스 파일도 일종의 테이블이다.

ClassFile {
  u4                magic;
  u2                minor_version;
  u2                major_version;
  u2                constant_pool_count;
  cp_info           constant_pool[constant_pool_count-1];
  u2                access_flags;
  u2                this_class;
  u2                super_class;
  u2                interfaces_count;
  u2                interfaces[interfaces_count];
  u2                fields_count;
  field_info        fields[fields_count];
  u2                methods_count;
  method_info       methods[methods_count];
  u2                attributes_count;
  attribute_info    attributes[attributes_count];
}

테스트 코드

이번 포스팅은

package classfiletest;

public class TestClass {
    private int x;
    private int y;

    public int sum() {
        return x + y;
    }

    public int sub(int z) {
        return x + y - z;
    }
}

코드(위)를 javac 로 컴파일 한 뒤 hex 편집기 로 해석한 16진수 값(아래) 와 비교하면서 공부 할 예정이다.

16진수 값은 1Byte 단위로 그룹핑되어 있는 모습이다.

javap -v 클래스파일 내용도 참고했다.

매직 넘버와 클래스 파일의 버전

매직 넘버 이 파일이 JVM 에서 사용하는 클래스 파일임을 나타내는 4Bytes(u4) 데이터. 이 파일이 클래스 파일인지 체크하는 용도. CAFEBABE 로 고정.

버전 번호 앞의 두 바이트(u2) = minor version 뒤의 두 바이트(u2) = major version

JDK1 은 Major Version 이 45 이다. 테스트 코드는 3D = 61 즉, JDK 17(61-45+1) 에서 컴파일 되었음을 알 수 있다. 마이너 버전은 대부분 0 으로 고정이다. JDK 1 의 일부와 12 에서 일부 기능의 베타 출시때 잠시 사용되었다.

상수 풀

클래스 파일에서 상수 풀 테스트 코드에서의 상수 풀 내용(length 표현 1개, 상수 23개) 상수 풀에서 쓰이는 타입의 17가지 테이블

필드 서술자, 메서드 서술자(descriptor)

• 필드 서술자 : 데이터 타입

• 메서드 서술자 : 매개 변수 목록(개수, 타입, 순서 포함), 반환 타입

  상수 풀에서 서술자 상수는 다음 표와 같이 표시된다. 객체 타입의 경우 FQCN 앞에 L 을 붙인다.

  배열 서술자는 차원 수 만큼 앞에 [ 가 붙는다. ex) int[] -> [I

  필드 서술자의 경우 위 식별 문자 하나만 표시되나, 메서드 서술자는 N 개의 매개 변수 타입과 반환 타입 모두 나타내므로 규칙을 알아야 한다. 예시를 몇가지 적어보자면

• void inc() -> ()V

• java.lang.String.toString() -> ()Ljava/lang/String

• int indexOf(Char[] source, int sourceOffset, int sourceCount, char[] target, int targetOffset, int targetCount, int fromIndex) -> ([CII[CIII)I

• 클래스 내부에서 쓰이는 상수를 저장하는 테이블 구조 데이터

• 상수 풀에 담기는 상수는 두가지 종류가 있다 : 리터럴 / 심벌 참조

  • 리터럴 : 자바에서로 치면 final로 선언된 문자열이나 상수
  • 심벌 참조
    • 모듈에서 임포트/익스포트 하는 패키지
    • 클래스와 인터페이스의 FQCN
    • 필드 이름과 서술자
    • 메서드 이름과 서술자
    • 메서드 핸들과 메서드 타입
    • 동적으로 계산되는 call site와 동적으로 계산되는 상수

• 심벌 참조는 클래스 파일을 클래스 로더가 로드하고 클래스를 해석할 때 실제 메모리 주소로 변환한다.

• 모든 데이터 타입은 u1 의 tag 값을 가진다. 자신 데이터 타입을 나타내는 id 라고 볼 수 있으며, 이걸 봐야 뒤에 나오는 몇개의 바이트 스트림이 어떤 의미인지 해석할 수 있다.

• bytes 값들은 값 자체를 나타낸다.

• index 값은 상수 풀의 상수를 1부터 순서대로 순번을 매겼을 때 해당 순서의 데이터의 포인터다. 이건 실제 예시를 보면 더 쉽다.

• 가장 앞의 2bytes 는 상수 풀에 들어있는 상수의 개수이다. 예시에서는 0x18(=24) 이며 23개의 상수를 가지고 있다는 뜻

  • 이 개수 데이터는 특별히 개수를 1부터 세기에 실제 개수는 -1 해야 한다.
  • 0은 상수 풀 항목을 참조하지 않음을 표현해야하는 특수한 경우에 쓰임

실제 예시 해석

• 위에서 상수를 모두 네모쳐놨다. 개수 데이터를 빼면 총 23개임을 볼 수 있다.
• 첫번째 데이터는 0A 00 02 00 03. tag=0x0A 면 CONSTANT_Methodref_info 이다. 데이터 구조를 보면 CONSTANT_Class_info 와 CONSTANT_NameAndType_info 의 인덱스를 각각 u2 데이터로 가지고 있다. 즉 02 인덱스 상수가 CONSTANT_Class_info, 03 인덱스의 상수가 CONSTANT_NameAndType_info 이다.
  • 생성자 메서드다.
• 두번째 상수가 CONSTANT_Class_info 인지 확인해보자. tag = 07 인 것을 확인할 수 있다. 실제 데이터가 07 00 04 이다. 04 인덱스에는 Utf8 상수 값이 들어있을 것이다.
  • 위에서 CONSTANT_Methodref_info -> CONSTANT_Class_info 로 왔으므로 인덱스 4에 있는 상수는 메서드 서술자의 완전한 이름 정보가 있을 것이다.
• 네번째 상수는 tag = 01 인 CONSTANT_Utf8_info 이다. 실제 바이트 스트림은 01 00 10 6A 61 76 61 2F 6C 61 6E 67 2F 4F 62 6A 65 63 74 이며 실제 데이터 영역만 디코딩해보면 java/lang/Object 이다.
  • 이런식으로 해석하며, 이 메서드 서술자가 어떤 메서드를 나타내는지 알기 위해선 첫번째 인덱스에 있는 데이터에서 CONSTANT_NameAndType_info 까지 따라가야 한다.

바이트 코드 상수값을 항상 이렇게 해석할순 없다. javap -verbose TestClass javap 는 클래스 파일 디스어셈블 명령이고, -verbose 옵션은 더 자세히 나타낸다.

이 명령을 실행하면 아래와 같이 상수풀을 쉽게 볼 수 있다.

CONSTANT_Utf8_info 의 length 가 u2 타입이다. 이는 2바이트이며 나타낼 수 있는 최대값은 65535 이다. 따라서 자바 프로그램에서 변수나 메서드의 이름은 64KB 를 넘으면 컴파일 되지 않는다.

접근 플래그

대상 클래스(인터페이스)의 접근제한자, final 등의 정보이다. u2, 2Bytes 정보이며 비트로 정보를 나타낸다. 따라서 총 16개의 정보를 true/false 로 나타내며, 현재는 다음과 같이 9개 비트만 쓰인다.

ACC_SUPER 에 대해 보충설명 하자면, invokespeical 바이트코드 명령어는 JDK 1.0.2 버전 이전과 이후 명령어 의미가 다르다. JDK 1.0.2 이상이라면 항상 이 플래그는 true 다.

테스트 코드의 경우 public 클래스이기 때문에, 0x0001 | 0x0020 = 0x0021 임을 볼 수 있다.

클래스 인덱스, 부모 클래스 인덱스, 인터페이스 인덱스

• 클래스 인덱스 : 상수 풀에서 클래스 정보를 가진 상수의 인덱스
• 부모 클래스 인덱스 : 상수 풀에서 부모 클래스 정보를 가진 상수의 인덱스(바로 윗 부모만)
  • 다중 상속 안되므로 컬렉션이 아닌 하나
• 인터페이스 인덱스 : 상수 풀에서 인터페이스 정보를 가진 상수의 인덱스 들
  • 인터페이스는 여러개 구현할 수 있으므로, _count 를 가진 컬렉션으로 표현

예시에서는 00 08 00 02 00 00 이다. 00 08 상수풀을 따라가면 classfiletest/TestClass 라는 클래스 이름이 나오고, 00 02 상수풀을 따라가면 java/lang/Object 라는 상위 클래스가 나온다. (상속을 선언하지 않았으므로 자바 기본 상위 클래스인 Object) 인터페이스 구현은 하지 않았으므로 00 00 으로 작성되었음을 알 수 있다.

필드 테이블

// 필드 테이블 구조
field_info {
  u2                access_flags;
  u2                name_index; // 필드 단순 이름의 상수풀 인덱스
  u2                descriptor_index; // 필드 서술자의 상수풀 인덱스
  u2                attributes_count;
  attribute_info    attributes[attributes_count];
}

• 필드 테이블은 클래스 변수와 인스턴스 변수를 포함한다. 메서드 변수는 필드가 아니므로 표현되지 않는다.
• 필드 테이블 부분은 필드 개수를 나타내는 fields_count(u2) 와 그 개수만큼의 field_info 테이블이 나열된다. 테스트의 경우 00 02 로 두개의 필드가 있다.
• 상속받은 필드는 나열하지 않는다.
• 중첩 클래스의 암묵적 this 처럼 코드에 나타나지 않고, 컴파일러가 자동으로 추가한 필드가 있을 수 있다.
• 자바에서는 필드 이름이 같은 오버로딩을 할 수 없지만, 클래스 파일에서는 이름이 같고 서술자가 다른 두 필드는 다른 필드로 취급한다. 이를 이용하여 필드 오버로딩이 가능한 언어를 만들 수 도 있겠다.

access_flag

field_info 의 첫번째 항목이다. 접근제한자 외 필드에 붙을 수 있는 것들을 표시한다.

테스트에서 선언한 두 필드 모두 private 외에는 딱히 없으므로, 두 필드 모두 00 02 이다.

name_index, descriptor_index

다음은 필드 단순 이름과 필드 서술자의 상수 풀 인덱스이다.

00 0B 00 0C -> x:I 00 0F 00 0C -> y:I 위 상수풀과 같이 해석하면 필드의 FQCN 이 아닌 단순 이름 + 타입(I. Integer) 를 나타내는 상수 풀의 인덱스를 가진다.

attributes

만약 값이 초기화가 되어 있고 한다면 이 attribute 테이블에 명시된다. 이는 이후 속성 테이블에서 더 설명할 예정.

메서드 테이블

method_info {
  u2                access_flags;
  u2                name_index; // 메서드 단순 이름의 상수풀 인덱스
  u2                descriptor_index; // 메서드 서술자의 상수풀 인덱스
  u2                attributes_count;
  attribute_info    attributes[attributes_count];
}

좀 길지만, 메서드 세개(00 03) 과 이후 세개의 메서드를 빨간색 네모로 구분했다. 생성자 1개와 선언된 메서드 2개가 그 내용이다.

• 메서드 테이블은 필드 테이블과 형태가 같다.
• 자동으로 만들어지는 메서드가 있을 수 있다. <init>(), <cinit>() 이 그 예다.
• 자바에서 메서드 오버로딩 판단에는 반환 타입이 들어가지 않는다. 즉, 자바에서는 메서드 이름과 매개변수가 같은데 반환 타입을 다르게 하여 오버로딩 할 수 없다. 반면 클래스 파일에서는 반환 타입 서술자만 다르게 하는것이 문제되지 않는다.

access flags

클래스 파일 레벨 Attributes

attribute 는 뒤에서 자세히 설명하겠다. 여기서는 테스트 클래스의 내용만 설명해보자.

• 00 01 : 클래스 파일 레벨의 attributes count. 1개
• 00 16 : attribute_name_index. 상수 풀에서 0x16(22) 를 조회하면 SourceFile 이 있다.
• 00 00 00 02 : 속성 테이블 길이
• 00 17 : 상수 풀의 0x17(23) 인덱스에는 TestClass.java 가 있다. 이 소스 파일의 이름이다.

Attributes

위에 나오지 않은 메서드의 연산 로직이라던지, 애너테이션, 런타임 디버깅에 사용할 줄번호 등은 어디에 있을까. 또 비교적 최근에 나온 sealed class, record class, module 임을 나타내는 정보는 어디 있을까.

이런 나머지 정보들이 들어가는 곳이 Attributes 다.

Attributes 는 아래 명시한 총 5가지의 사용처에서 각각 사용처를 설명하기 위한 값들이 들어간다. 예를들어 클래스 파일 attribute 로 Record Attributes 가 포함된다면 해당 클래스는 레코드 클래스임을 클래스파일에서 명시한 것이다.

Attributes 종류

JDK25 기준 클래스파일 구조에서 Attributes 는 총 30가지이다.

각각의 Attribute 는 사용처가 다르다. 예를 들어 Code Attribute 는 메서드 테이블에서만 쓰인다. 반면 애너테이션을 표현하는 RuntimeVisibleAnnotation Attribute 는 클래스 파일, 메서드 테이블, 필드 테이블, Record Attribute 의 record_component_info 에서 공통적으로 쓰일 수 있는 속성이다.

Attributes 사용처

JDK25 기준 클래스파일 구조에서 Attributes 타입을 쓰는 곳은 다섯곳이다.

• 클래스파일
• 필드테이블
• 메서드테이블
• Code Attribute
• Record Attribute 의 record_component_info

Attributes 공통 구조

attribute_info {
  u2 attribute_name_index;
  u4 attribute_length;
  u1 info[attribute_length];
}

Attribute 는 위의 공통 구조 하에서 각각 다른 형태를 가진다. 각 Attribute 가 다른 구조이지만 위 구조는 공통적으로 포함한다.

Code 속성

Code_attribute {
    u2 attribute_name_index; // Code 상수를 가지고 있는 상수 풀의 인덱스
    u4 attribute_length; // 이후 나올 모든 Code Attribute 의 길이
    u2 max_stack;
    u2 max_locals;
    u4 code_length;
    u1 code[code_length];
    u2 exception_table_length;
    {   u2 start_pc;
        u2 end_pc;
        u2 handler_pc;
        u2 catch_type;
    } exception_table[exception_table_length];
    u2 attributes_count;
    attribute_info attributes[attributes_count];
}

코드 속성은 어쩌면 가장 중요한 속성이다. 메서드 테이블의 Attribute 로 존재하며, 메서드의 바이트 코드 명령어를 담고 있다.

• max_stack : 피연산자 스택의 최대 깊이. 메서드 실행 중 이 스택의 깊이를 절대 넘을 수 없으며, 가상 머신은 깊이가 이 값만큼인 피연산자 스택을 스택 프레임에 할당
• max_local : 지역 변수 테이블에 필요한 저장소 공간. 단위는 변수 슬롯(32비트. long, double 은 슬롯 두개 차지). 지역 변수의 개수가 아니라 슬롯 개수임을 유의. 지역 변수 테이블에는 매개 변수(this 포함), try-catch 매개 변수 예외, 지역 변수 모두 들어간다. 또한 이 값은 단순 지역 변수 테이블에 들어갈 요소 개수가 아니다. jvm 은 메모리를 절약하기 위해 슬롯을 최소한으로 만들어 재사용한다. 따라서 동시에 존재해야 하는 최대값을 max_local 로 정한다.
• code_length : 코드 길이. u4 이지만 jvm 명세에 65535 라 정해져서 이를 넘을 수 없다. 사실상 u2 타입이다.
• code : 실제 바이트 코드 명령어 스트림이다. 바이트 코드 명령어는 u1 이며, 실제로 바이트코드는 1바이트가 표현한 256개 이하이다. 각 바이트 코드 명령어는 1바이트 OpCode 와 맵핑되어 있다. 이 부분을 해석할 때에는 명령어의 바이트도 필요하지만 명령어가 매개 변수를 필요로 하는가도 알아야 함. 예를 들어 invokespecial 같은 경우 뒤에 2바이트의 매개변수가 따라온다. 매개변수는 상수 풀의 인덱스 값이 적힌다.
  • 명령어가 실행되어야 하는 순서대로 클래스 파일에 작성된다.

javap -verbose 를 통해 code 를 보면 args_size 도 나온다. 메서드 매개 변수의 개수이며, 메서드 서술자로 계산된 값이다. this 도 암묵적으로 들어가기 때문에 인스턴스 메서드의 경우 기본적으로 매개 변수가 없다면 1이다. Static 메서드의 경우 this 가 없기에 매개 변수가 없다면 0이다.

• exception_table : 예외 처리 구문이 있는 경우 이 테이블이 생성된다. 예외 처리 대상 바이트코드 명령어 인덱스 범위(try 블록)인 start_pc 와 end_pc, 예외 처리 코드 (catch 블록) 인 handler_pc, 그리고 예외 타입인 catch_type 네가지 필드를 가진 테이블이 try-catch-finally 구문 개수만큼 클래스 파일에 만들어진다. (아래 예시와 같이)

그외

• Exceptions : 메서드 레벨에 throws 로 명시된 예외 정보
• LineNumberTable : 코드 라인넘버와 바이트 코드 오프셋의 매핑이다. 이 기능 덕분에 예외시 스택 트레이스에 라인 넘버가 나오며, 디버깅시 중단점을 적용할 수 있다.
  • javap 에 LineNumberTable 과 Code Attribute 를 같이 보면 어떤 라인에서 어떤 바이트 코드 명령어가 쓰인건지 알 수 있다.
• LocalVariableTable : Code 의 속성으로, 지역 변수 테이블 안의 변수와 소스 코드의 변수 사이의 관계를 나타낸다. 지역 변수 유효 범위 바이트 코드 인덱스와 변수 이름, 서술자가 있고 지역 변수 테이블에서의 슬롯 인덱스가 있다.
  • 이 정보를 통해 외부에서 매서드 사용시 매개 변수의 이름을 알 수 있다. 이게 없으면 arg0 이런식으로 보임
  • 책에는 기본 활성화 된다 되어있는데... 나는 javac -g 옵션을 줘서 컴파일해야 보인다.
  • Code 의 속성이므로 Code 속성이 없는 abstract 클래스의 메서드나 인터페이스 메서드의 매개 변수를 포함할 수 없다. 이를 해결하려면 MethodParameters 속성을 사용한다.
• LocalVariableTypeTable : LocalVariableTable 와 같은 내용이나 제네릭 매개 변수용이다. 제네릭이라 Code 속성이 아닌 클래스 파일 속성이다.(제네릭은 클래스 객체 단위로 정해지니) 타입 소거 때문에 서술자는 매개 변수화 된 타입 정보를 담을 수 없으므로 따로 만들었다.
• SourceFile : 파일 이름이다. 이게 없으면 예외 발생시 어느 파일에서 발생했는지 보이지 않는다.
• ConstantValue : 필드 테이블의 속성이다. 정적 변수(클래스 변수, static) 에 본인이 가진 상수 풀 인덱스의 값을 초기화 하라고 알리는 역할
  • 클래스 변수는 클래스 생성자인 <clint>() 또는 ConstantValue 속성 중 하나를 사용해서 초기화할 수 있다. 오라클 javac 는 final static 중 기본타입과 String 을 ConstantValue 를 만들어 준다.
  • final static 변수에 ConstantValue 를 만들긴 하지만 해당 필드에 ACC_FINAL 플래그가 켜지진 않는다. 자바 가상 머신 명세에는 ACC_STATIC 만 활성화 하도록 명시하였고, 오라클 javac 가 final static 에 대해 만든다는건 컴파일러에서 구현된 제약이다.
  • ConstantValue 의 속성은 상수 풀의 인덱스를 가진다. 따라서 클래스 변수 중 객체 타입은 ConstantValue 를 통해 초기화할 수 없기에 오라클이 그렇게 만든 것.
• InnerClasses : 내부 클래스들과 호스트 클래스의 관계
• Deprecated : 내용이 boolean 인 속성. @Deprecated 에 생성됨
• Synthetic : 내용이 boolean 인 속성. 컴파일러가 자동으로 추가한 필드나 메서드를 표현.
  • ex) enum 의 원소 배열, 중첩 클래스의 브릿지 메서드
  • <clinit>(), <init>() 는 자동으로 만들어지긴 하지만 예외
• StackMapTable : Code 의 속성. 클래스 로딩시 파일의 타입 검증기에서 타입 검사와 적법성 검사에 사용. JDK5 까지의 타입 추론 검사기를 대체하여 성능이 좋아진 역사적인 그런..
• Signature : 클래스 파일, 필드 테이블, 메서드 테이블 다 가능. 제네릭 시그니처 정보를 담음. 이거 덕분에 리플렉션으로 제네릭 타입 정보를 얻을 수 있음.
• BootstrapMethods : 클래스 파일 속성. invokedymanic 명령어가 참조하는 부트스트랩 메서드 한정자가 담긴다.
• MethodParameters : 메서드 테이블의 속성이다. 메서드 파라미터의 이름이 담긴다. LocalVariableTable 이 Code 속성에 있어서 추상 메서드나 인터페이스 메서드의 매개 변수를 표현할 수 없음을 보완하기 위해 만들어졌다.
  • 컴파일시 -parameters 옵션을 명시적으로 줘야 한다. (기본적으로 생성되지 않는다)
  • 이를 통해 리플렉션으로 메서드 이름을 가져올 수 있다.
    • 아래 예시 코드 [1] 의 코드를 -parameters 컴파일 옵션을 주고 안주고 차이를 보자. 출력에 이름이 args0 이렇게 보이다가 실제 매개 변수 이름이 보일 것.
  • jar 파일 만들때 이 옵션 없이 만들면 사용자가 불편할 것. spring 을 gradle 로 jar 파일 빌드하면 이 옵션이 자동으로 들어간다. (빌드 파일을 javap 로 보면 이 속성이 있음)
• RuntimeVisibleAnnotations, RuntimeInvisibleAnnotations, RuntimeVisibleParameterAnnotations, RuntimeInvisibleParameterAnnotations : 애너테이션 정보를 담는다. 리플렉션으로 애너테이션 정보를 가져올 때 사용된다.
• Record : 클래스 파일 속성이며, 해당 클래스가 Record Class 임을 나타낸다.
• PermittedSubclasses : 클래스 파일 속성이며, 해당 클래스가 Sealed Class 임을 나타낸다.
  • 허용하는 클래스의 상수 풀 인덱스 목록을 가진다.
  • Sealed Class 는 자신 내부에서만 하위 클래스를 가질 수 있는 상위 클래스다. 따라서 하위 클래스가 딱 정해져서 코틀린에서는 switch 에서 else 를 쓰지 않아도 되는 그런 부가적인 이점이 있다.

예시 코드

[1]

import java.lang.reflect.Method;
import java.lang.reflect.Parameter;

public class TestInterface {
    public static void main(String[] args) throws Exception {
        Method m = TestInterface.class.getDeclaredMethod(
                "transfer",
                String.class, String.class, long.class
        );

        System.out.println("=== parameter info ===");
        for (Parameter p : m.getParameters()) {
            System.out.println(
                    "name=" + p.getName()
                            + ", isNamePresent=" + p.isNamePresent()
            );
        }
    }

    static void transfer(String fromUserId,
                         String toUserId,
                         long amount) {
        // no-op
    }
}

따라서 GC 는 지연 시간을 줄이는 방향으로 발전했다.

G1 GC 은 Young GC 및 Mixed GC 에서 생존한 객체를 다른 Region 으로 옮기는 소위 Compact 라 불리는 작업은 STW 로 동작한다. 저지연 컬렉터는 Compact 를 유저 스레드와 동시에 진행하여 아주 낮은 일시 정지로 낮은 지연 시간을 달성하는 컬렉터이다.

처리량 영향을 최소로 하면서 10ms 이하의 일시 정지 시간이 목표다.

Shenandoah

개요

섀넌도어는 레드햇에서 만든 저지연 컬렉터이다. 포워딩 포인터 기법을 이용하여 Compact 를 동시에 처리한다.

Oracle JDK 에서는 제공하지 않으므로, Oracle JDK 를 유료로 지원받을 계획이 있다면 사용하지 않는게 좋다.

세대구분 셰넌도어도 존재하나, 처음에는 세대구분이 없었다. 세대 구분 없는 셰넌도어 기준으로 설명한다.

GC Cycle

https://wiki.openjdk.org/spaces/shenandoah/pages/25002018/Main?utm_source=chatgpt.com

OpenJDK 문서에 따르면 셰넌도어는 9가지 단계로 이뤄진다.

1. 최초 표시 : GC Root 를 스캔 마킹

2. 동시 표시 : 마킹된 GC Root 로 부터 동시 마킹, 변경이 발생하면 SATB 큐에 기존 값 저장

3. 최종 표시 : 동시 마킹시 발생한 참조 변경(SATB 큐)에 의해 발생한 마킹을 시작 스냅샷 기준으로 수정하기 위한 최종 작업과 회수 집합을 생성

4. 동시 청소 : 빈 리전 회수

5. 동시 이주 : 마킹시 생존한 객체를 유저 스레드와 동시에 다른 리전으로 복사하며 Compact

6. 최초 참조 갱신 : 동시 참조 갱신을 위한 준비 - 동시 이주 작업이 모두 끝나길 기다리는 벽 역할을 하는 STW

7. 동시 참조 갱신 : 생존한 객체를 참조하는 곳을 변경.

   • 기존 마킹을 진행한 객체 참조에서 복사/이주 한 객체 참조로 변경.
   • GC Root 에서 객체 참조를 따라가는 방식이 아닌, 힙 메모리를 물리적인 순서대로 선형 검색하며 변경.
   8. 최종 참조 갱신 : GC Root 의 참조도 복사/이주 한 객체 참조로 변경. GC Root 이기에 STW.

8. 동시 청소 : 4번과 같은 역할. 참조 갱신까지 완료된 후 빈 영역 회수

포워딩 포인터와 barrier

메모리 파편화를 피하기 위해서는 Compact 과정이 불가피하다. 즉, 객체가 다른 위치로 이동해야 한다는 것이다.

이 때 고려해야할 것은 두가지다. 첫번째로, 객체를 이동할 때 복사를 하고 기존 객체를 나중에 정리할 것이냐 or 새 위치에 새로운 객체를 생성하면서 기존 객체를 삭제 할 것이냐다. 언뜻 보면 객체를 두벌 관리하여 공간을 차지하는 복사보단 삭제후 생성이 좋아 보인다. 하지만 삭제 - 생성하게 되면 기존 객체가 사라지니 반드시 기존 객체에 대한 참조를 새로운 객체 참조로 변경하는 것도 같이 발생해야 한다. 하지만 특정한 하나의 객체를 새로 생성할 때 해당 객체를 사용하는 곳을 모두 찾아 참조를 변경하는 것은 STW 에서 일어나야 하며, 이는 시간이 많이 걸린다. 따라서 두벌을 유지하는 복사 이주 방식을 택한다.

두번째로, 그럼 복사 이동을 택했을 때 객체를 참조하는 곳의 참조값을 이전 참조값에서 새 참조값으로 변경하는 방법이다. 이는 아래에서 자세히 설명하겠다.

동시 복사/이주의 문제

https://shipilev.net/talks/javazone-Sep2018-shenandoah.pdf

위 그림은 7번 동시 참조 갱신 중의 살아남은 객체의 상태다. 객체는 동시 이주 단계를 거쳐 두벌로 복사된 상태이다. 검정 네모는 GC Root 이며, 객체를 참조하는 GC Root 는 총 4개가 있다.

동시 참조 갱신 단계 중 2개의 GC Root 참조는 이주/복사된 새 객체를 참조하도록 갱신되었으나, 2개의 GC Root 참조는 아직 이주/복사 이전 객체를 참조한다. 이러한 타이밍은 반드시 있다.

이 때 만약 예를들어 참조를 옮기지 못한 왼쪽의 GC Root 를 통해 값의 수정이 이뤄지고(y=2 -> 4), 참조 갱신이 끝난 후 값을 조회한다면 수정되지 않은(y=2) 의 값을 읽어버릴 수 있다.

포워딩 포인터와 barrier

이를 위해 컬러 포인터 개념이 있다.

포워딩 포인터는 위와 같이 기존 객체 layout 앞에 추가된 포인터이다. 객체 레퍼런스를 가지고 있으며, 시스템에 따라 32/64 bits 이다.

이 포인터는 처음에는 위 그림처럼 자기 자신 객체 참조 주소를 가진다.

복사시점의 상태다. from-space(기존 객체) 와 to-space(복사/이동 된 객체) 의 포워딩 포인터는 모두 자기 자신을 가리킨다.

복사가 완료되면 from-space 포워딩 포인터를 to-space 를 가리키도록 변경한다. 이 동작에는 동시성 문제가 있는데,

1. 복사
2. 유저 스레드 의 기존 참조 수정
3. from-space 포워딩 포인터 변경

위와 같이 복사 후 포워딩 포인터를 옮기기 전 mutator 스레드의 객체 참조가 발생하면 from-space 객체를 볼 수 있다. 따라서 쓰는 동작에서 CAS 를 이용한 write barrier 가 존재하여 to-space 객체에 쓸 수 있도록 동작한다.

이 그림은 참조 갱신 중에도 정상적으로 포워딩 포인터를 통해 to-space 의 객체를 수정하는 예시다. 모든 참조 갱신이 완료되면 기존 from-space 를 정리할 수 있다.

LoadReferenceBarrier

셰넌도어 1.0 에서는 두벌로 존재하는 객체에서 힙 일관성을 지키기 위해 모든 참조에 대해 Write/Read 배리어를 건다.

https://developers.redhat.com/blog/2019/06/27/shenandoah-gc-in-jdk-13-part-1-load-reference-barriers?p=602377

위의 코드에서 value 객체가 primitive type 이라도 barrier 를 건다. barrier 를 쓰는 이유는 참조 타입 객체를 읽거나 쓸 때 해당 참조 타입 객체가 이동되는걸 방지하기 위한 것이라서, primitive type 은 사실 barrier 를 걸지 않아도 된다.

LoadReferenceBarrier 의 탄생으로 객체를 읽을때 to-space 에서 읽는것을 보장함으로서 barrier 의 수를 많이 줄일 수 있었다.

포워딩 포인터 객체 헤더 통합

포워딩 포인터는 태초에 위처럼 마크 워드 앞에 자리를 차지했다. 마크 워드는 최하위 2비트의 플래그 비트로 여러 데이터를 표현할 수 있었는데, 그 자리에 뒀으면 안됐을까?

기존의 섀넌도어에서는 모든 객체 접근에서 to-space 를 보기 위해 마크워드 디코딩 “매번” 실행하여 검사하는 hotpath가 되어버려서 비용이 너무 컸다.

Load Reference Barrier 의 등장으로 포워딩 포인터는 mark-word 에 병합되었다.

1. Barrier 가 모든 객체, 특히 primitive 접근에 필요하지 않다.
   • 복사가 되었는지 확인하기 위해 포워딩 포인터를 확인하는 횟수가 많이 줄어 디코딩 비용이 줄었다.
2. from-space 객체에 더이상 접근하지 않는다.
   • from-space 의 내용을 모두 지우고, 포워딩 포인터 데이터만 남긴다.
   • 복사되어 포워딩해야 하는가, 아직 복사 안되어 포워딩 안해도 되는가의 2가지만 디코딩 하면 되어 디코딩 비용이 줄었다.

이로 인해 메모리 사용량이 많이 줄게 되었다.

https://developers.redhat.com/blog/2019/06/28/shenandoah-gc-in-jdk-13-part-2-eliminating-the-forward-pointer-word?utm_source=chatgpt.com

ZGC

개요

ZGC 는 오라클에서 주도로 만든 저지연 컬렉터이다. 마찬가지로 Compact 를 유저 스레드와 동시에 진행하여 저지연을 달성한다.

Oracle 문서를 보면 다음과 같이 표현되어 있다. Scalable Low-Latency Garbage Collector Scalable 이란, 힙의 크기나 객체의 양이 많아져도 여전히 낮은 일시 정지 시간과 높은 처리량을 낼 수 있다는 말이다.

세대구분 ZGC도 존재하나, 처음에는 세대구분이 없었다. 세대 구분 없는 ZGC 기준으로 설명한다.

Page

ZGC 는 메모리를 Page 로 관리한다. (G1 의 리전과 비슷) G1 과 다르게 ZGC 의 Page 는 소/중/대 세가지가 존재한다.

• 소 : 2MB 고정 크기. 256KB 미만의 작은 객체 저장용
• 중 : 32MB 고정 크기. 256KB 이상 4MB 이하 객체 저장용
• 대 : 크기가 동적으로 변할 수 있음. 4MB 이상의 큰 객체 저장용.
  • 대는 큰 객체 하나만 저장. 따라서 32MB 를 담을 수 있는 중리전보다 가지고 있는 실제 객체크기가 적을 수 있음.
  • 큰 객체의 복사 비용이 높기에, 재배치의 대상이 되지 않음.

Page 는 동적으로 생성/파괴되며, 동적으로 바뀔 수 있다.

GC Cycle

1. STW1 : Start Of The ZGC

이 단계에서는 크게 세가지 일을 한다.

1. Good Color 를 001(marked0) 또는 010(marked1) 중 선택한다. 전 사이클에 사용되지 않은 것이 선택된다.
2. 동시 마킹 중 새로 생성된 객체를 할당할 Page 를 생성한다. 이 Page 에 있는 객체는 모두 이번 사이클에서 Marked 로 간주하여 Mark Stack 에 적재한다.
3. GC Root 를 마킹 : GC Root 에 Mark Barrier 가 적용된다.

2. Concurrent Marking/Remapping

위는 마킹 루프 스켈레톤 코드다. 마크 스택의 객체를 pop 하여 mark_obj(bitmap 에 마킹)하고, MB(Marking Barrier) 로직을 실행한다. 아래는 마킹 배리어(MB) 는 마킹 단계에서 컬러포인터를 확인하는 과정, 로드 베리어(LB) mutate thread 의 객체 참조 과정에서 컬러포인터를 확인하는 과정을 보여준다.

이 단계에서는 객체 마킹과 이전 사이클 Relocation 객체의 Remapping 을 동시에 진행한다.

위 marking loop 스켈레톤 코드가 이 단계에서 진행하는 내용을 간략화 한 것이다. mark_obj() 함수에서는 bitmap 에 살아있음을 마킹하고, 이후에 해당 객체의 필드들을 순회하며 Mark Barrier 를 적용한다.

MB 에서는 컬러포인터를 확인하고 EC 에 포함되는 객체라면 Remapping, 아니면 컬러포인터 수정을 한 뒤 Marking Stack 에 쌓는다.

이 단계에서 사용되는 EC 는 이전 Cycle 에서 만들어진 EC

이 동작의 반복으로 살아있는 객체 그래프를 순회하며 Marking 과 Remapping 을 동시에 처리하게 된다. 그리고 그 첫 시작은 STW1 에서 Stack 에 넣은 GC Root 일 것이다.

따라서, 이 단계가 진행된 후에는 Dangling(Relocation 이전 주소를 가진 참조) 가 없음이 보장된다.

Mutator Thread 의 객체 참조시 사용되는 LB 와 다른점은 두가지다.

1. 마킹에 사용되므로 반환값이 void 인 것
2. 모든 객체 그래프를 순회하면서 마킹해야하므로 컬러포인터가 정상이더라도 fast path 없이 모두 slow path 적용하여 marking stack 에 집어넣는것

2번 때문에 같은 객체가 중복으로 Marking Stack 에 들어가는 부작용이 있지만, Bitmap Marking 동작은 CAS 로 Thread-Safe 하므로 문제는 없으며, Mutator Thread 의 Stack 에는 할일이 많지만 GC Thread 가 할일이 없어 Marking/Remapping Phase 가 끝남을 방지하기 위함이다. (G1 과 같이 이것도 Mutator Thread 에 로컬 스택이 있고, 글로벌 스택이 있는듯)

또한, ZGC 는 incremet-update 방식(Not SATB) 을 사용한다. Mutator Thread 에 의해 접근된 객체는 LB 로 Marking Stack 에 적재되며 동작한다.

마킹에 Mark0, Mark1 비트 두개가 사용되는 이유는 전 사이클의 Remapping 과 현 사이클의 Marking 이 동시에 진행되기 때문이다. 예를들어 전 사이클에서 마킹되었지만 Relocation 은 되지 않은 객체가 있다고 가정하자. 현 Marking/Remapping 에서 Çolor Pointer 는 0001. 현 사이클에서도 살아있는 객체라 새로 0010 으로 마킹 될 예정이다. 하지만 마킹이 진행되기 전에 Mutator Thread 로 부터 참조 조회가 있었고, LB 가 진행되는 상황이라 치자. 이 때 만약 Marking 을 나타내는 필드가 하나라면, 이전 사이클에는 마킹했으나 현 사이클에는 아직 마킹을 하지 않아서 이번 사이클의 good color 로 색칠해야함 을 표현할 수 없다. 비트가 하나라면 그냥 1 일 것이고 이번 사이클에서 마킹한 것인지 전 사이클에서 마킹한 것인지 구분할 수 없다는 것이다. 이는 결국 Marking 과 Remapping 을 동시에 진행함으로서 발생된 것이며, Marking 을 표현하는데 두 비트를 사용하는 것은 결국 성능상의 트레이드 오프라 할 수 있다.

3. STW2 : End of the Marking Phase

Mark Stack 이 비어 모든 객체가 마킹 되길 기다리는 STW

4. Reference Processing

이 단계는 Soft, Weak, Phantom Reference 를 처리하는 단계인데, 복잡하여 일단 생략

5. Selection Of Evacuation Candidate

Evacuation Candidate (또는 Relocation Set) 은 살아남은 객체가 많지 않아 살아남은 객체를 다른 곳으로 이주시키고 해당 Page 를 회수할 Page 의 집합이다.

이 단계에서는 몇가지 정보를 삭제한다.

1. 이전 Cycle 의 EC 집합을 삭제
2. 이전 Cycle EC Page 의 Fowarding 테이블 삭제 : Marking 단계가 지나며 Dangling Reference 가 없음이 보장되었음이 근거
3. 살아있는 객체가 하나도 없는 Page 회수

그리고 EC 를 만든다. 먼저 이번 GC Cycle 에서 새로 생성된 객체를 넣기 위해 STW1 에서 생성한 Page 를 제외한 모든 Page 중, 살아있는 객체가 적은 순으로 정렬(살아있는 객체 집계값은 marking 에서 생성)한 후, 파편화 임계값에 따라 Relocation 대상 Page 를 선정하여 EC 를 완성한다.

큰 Page 는 Relocation 대상이 아니다. EC 에는 소, 중 Page 만 포함

STW3 : Transitioning to Relocation

1. Good Color 를 0100(Remapped) 로 변경한다.
2. GC Root 가 EC 를 바라본다면, 해당 EC 를 relocation 하고 그렇지 않다면 단순 color 를 0100 으로 수정한다.
   • GC Root 작업을 하기에 STW

Mark0/1 과 Remapping 의 Load Barrier 차이 4번줄에 EC 로 변수는 같으나 Mark 단계 LB 의 EC 는 이전 Cycle EC 이고, Remapped 단계 EC 는 Selection of Evacuation Candidate 에서 선정한 EC 인 점이 다르다. 또한, EC 에 포함되었을때 왼쪽은 단순 remapping 이지만 오른쪽은 relocation 을 한다.

Relocation

이 단계의 스켈레톤 코드는 위와 같다. EC Page 의 객체들을 Relocation 하면서 Fowarding 테이블에 저장한다. Fowrading 테이블을 이후 LB, MB 에서 사용된다.

Relocation 이 끝난 Page 는 메모리에서 해제한다.

이 단계가 끝나서 객체가 모두 이주하더라도 여전히 이전 객체 참조값을 가진 곳이 있을 수 있다. 컬러포인터 + Barrier + Fowarding Table 덕에 이는 급하게 처리할 일은 아니며, 다음 사이클의 Marking/Remapping 단계에서 빠짐없이 처리될 것이다.

컬러포인터

ZGC 는 동시 이주를 실현하기 위한 기술

컬러포인터는 객체 참조 주소값 자체에 포함되는 4비트의 메타데이터로서, GC 와 동시에 실행되는 유저의 객체 참조시 참조가 이동했더라도 정상적으로 이동한 참조를 찾아갈 수 있게 하는 메커니즘이다.

각 객체의 컬러포인터는 GC 사이클에서 Good 또는 Bad 상태를 나타낸다. Good 상태는 해당 참조값을 바로 사용할 수 있음이며, Bad 는 객체가 이동했을 수 있으니 체크해야한다(potentially invalid) 는 뜻이다.

참조값의 Load 시 미리 정의된 Load Barrier 트랩이 발동하여 Good 이라면 참조값을 반환하고, Bad 라면

컬러 포인터 비트들

• marked0, marked1 : 이번 마킹 사이클에서 이미 live로 ‘표시(mark)’되었다고 알려져 있는가?
  • 왜 2비트인지는 위 Cycle 설명 참조
• remapped : 리로케이션 셋(relocation set) 안(옛 위치)을 가리키지 않는다고 알려져 있는가
  • 1 : 재배치 집합을 가리키지 않는다는게 확실하다 = 재배치된 객체 주소
  • 0 : 재배치 집합을 가리킬 수 있다 = 재배치 필요 확인 후 재배치 또는 참조 갱신

Good Color, Bad Color 판단

GC Cycle 에서는 위 그림과 같이 현재 시점의 Good Color 가 정해진다. Mutator Thread 의 참조 또는 GC Thread 의 Marking 이 실행되면, 참조값의 Color pointer 와 현재 시점의 Good Color 를 비교하여 다르다면, Bad 상태로 간주하고 처리를 한다. 이 동작은 Barrier(LB/MB) 로서 동작한다.

Color Pointer 를 확인하고 참조를 최신화하는 이 동작은 3군데서 발생한다.

1. Marking/Remapping Phase 에서 Marking 시 Marking Barrier
2. Marking/Remapping Phase 에서 Mutator 에 의한 조회 Load Barrier
3. Relocation Phase 에서 Mutator 에 의한 조회 Load Barrier

각 단계에서 실제로 어떤 단계로 어떻게 처리하는지는 위의 Cycle 설명에서의 스켈레톤 코드를 참조하자.

self healing

위 Cycle 에서 설명했듯, ZGC 는 Relocation 직후에 이동한 참조값에 대해 STW 를 하여 갱신하지 않는다.

유저 스레드 동작과 함께 천천히 진행한다.

이는 객체 조회시 Relocation 이전 참조를 가지고 있다 하더라도, Color Pointer 를 통해 이전 참조임을 판단하고 Fowarding Table 을 통해 새 참조값을 가져오는 동작을 객체를 참조하는 Mutator Thread 가 직접 할 수 있기 때문이다.

이를 Self-Healing 이라 한다.

Multi Mapping

https://dev.java/learn/jvm/tool/garbage-collection/zgc-deepdive/

위 그림은 아마 객체 주소에 42bits 를 사용하던 시절의 그림이라 4, 8, 10 이 된것 같다. 44bits 를 사용한다면 1, 2, 4 가 되어야 할 듯.

Color Pointer 는 객체 참조 주소값 자체에 저장된다. 주소를 나타내는 값을 임의로 변경했다. ZGC 가 관리하는 메모리 공간에서는 이를 알고 있으나, OS 는 다르다. Color Pointer 가 다르면 다른 주소로 인식 할 뿐이다.

하지만 컬러포인터가 다르더라도 이들은 모두 같은 객체다. 따라서 자바의 가상 주소 공간에서 Color Pointer 로 다른 주소 공간을 나타내더라도 OS 메모리 공간에는 하나의 메모리 주소를 표현하도록 Multi-Mapping 을 사용한다.

컬러 포인터의 장점

• 한 리전안의 객체들이 이동하면 그 즉시 해당 리전을 재사용할 수 있다. Self Healing 덕분이다. 섀넌도어처럼 이전 객체를 유지 할 필요가 없다.

  • Cycle 에서 STW3 에 빈 Page(마킹이 하나도 없는 Page) 를 최대한 빨리 회수하고, ReLocation 과정에서도 Page 단위로 Relocation 한 뒤 바로바로(최대한 빨리) Page 를 회수한다.

• Read Barrier(LB/MB) 만 가지고도 처리할 수 있으므로 장벽의 수가 많이 줄어든다.

• 아직 자바 객체 주소에는 사용하지 않는 Bit 가 많이 남아서, 확장 가능성이 열려 있다.

https://openjdk.org/jeps/333

컬러 포인터의 제한

• 32bit 시스템은 ZGC 를 못쓴다.
• Compressed OOPS 를 사용하지 못한다.
• ZGC 주소공간 메모리가 16TB(2^44) 로 제한된다.

세대 구분 저지연 컬렉터

세대 구분 이론은 세가지 가설로 탄생했다. 그 중 대다수 객체는 일찍 죽는다는 가설로 Young GC 를 자주 실행시킨다. 이는 곧 죽을 확률이 높은 객체만을 GC 판별한다는 것이다. 이는 GC 의 CPU 사용 효율을 높일 수 있다.

ZGC 나 섀넌도어는 처음에는 세대 구분 없이 이를 출시했다. 세번째 가설에 의한 세대간 참조를 해결하는 기억 집합이 필요 없었기에, 메모리 사용량은 약간 줄 수 있었다.

하지만 결국 매 GC 마다 (세대 구분 GC 였다면 Old 였을) 오래 살아남는 객체를 매번 판별해야했다. 이것이 결국 ZGC, 섀넌도어도 세대 구분으로 발전하게된 이유다.

세대 구분 ZGC 는 높은 CPU 효율로 단일 세대 ZGC 보다 높은 처리량을 달성할 수 있다. 또한, 일시 정지 시간이 줄어들기에 P99 Latency 를 완화할 수 있다.

단일 세대 GC 의 가장 큰 문제는 할당 지연(allocation stall) 이다. 이는 GC 속도가 객체 할당속도보다 느릴 때 발생한다. 세대 구분 ZGC 는 같은 일시 정지 시간에 더 많은 객체를 정리 할 수 있으므로 이 또한 많이 완화되었다.

https://inside.java/2023/11/28/gen-zgc-explainer/

저지연 가비지 컬렉터의 선택

저지연 가비지 컬렉터는 회수조차 유저 스레드와 동시에 실행하기 때문에 극단적인 일시정지 시간 감소를 가져올 수 있었다.

일시 정지 시간이 길면 어떤게 나쁠까? P99 의 유저 경험이 나빠질 수 있다는 것이다. 한번씩 발생하는 긴 일시정지는 유저에게 한번씩 큰 지연 시간을 겪게 할 것이다. 반면 유저 스레드와 동시에 실행하는 것들은 많아지기 때문에 전체적인 유저의 지연 시간은 좀 더 늘어날 수 있다. CPU 자원을 나눠 쓰며 컨텍스트 스위칭 등이 일어날 수 있기 때문이다.

정리하자면 이렇다. 긴 정지 시간을 줄일 수록 P99 의 Latency 는 완화할 수 있으나 전체적인 Latency 는 조금 늘어날 수 있으나. 긴 정지 시간을 허용하면 그 시간동안 오롯이 GC 를 실행하여 전체적인 처리량 및 Latency 는 줄어든다. 하지만 긴 정지 시간에 요청을 보낸 유저는 긴 시간 후 응답을 받을 것이다.

따라서 유저 대상 서비스와 연결된 자바 애플리케이션이라면 정지 시간을 줄이는 저지연 컬렉터가 좋다. 반대로 유저를 대상으로 하지 않고 뒷단에서만 동작하는 배치, 데이터 정제 등의 작업 들은 처리량 컬렉터가 좋을 것이다.

이론상은 위와 같은데, 현재 많은 연구결과들은 처리량이든 지연시간이든 ZGC 가 좋다~ 라는 것 같다. 이는 참고만 하고 각자 환경에서 테스트하는게 제일 중요할 것.

ZGC 기대 가능한 장점

• P99 응답 지연의 감소

기대 가능한 단점

• barrier 의 증가
• threadlocal handshake
• gc 와 application 의 리소스 경쟁으로 인한 처리량 감소
• zgc 의 경우 compressed oops 의 사용 불가 https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b

참고

섀넌도어

[논문] Shenandoah - Christine H. Flood... https://tech-notes.accel.dk/programming/java/java12/docs/PPPJ2016.pdf?utm_source=chatgpt.com

shipliev 이사람 자료들이 좀 자세하고 좋음.. https://shipilev.net/talks/javazone-Sep2018-shenandoah.pdf

openjdk https://wiki.openjdk.org/spaces/shenandoah/pages/25002018/Main?utm_source=chatgpt.com

섀넌도어 제작한 redhat 자료. https://developers.redhat.com/blog/2019/06/27/shenandoah-gc-in-jdk-13-part-1-load-reference-barriers?p=602377 https://developers.redhat.com/blog/2019/06/28/shenandoah-gc-in-jdk-13-part-2-eliminating-the-forward-pointer-word?utm_source=chatgpt.com https://developers.redhat.com/blog/2019/07/01/shenandoah-gc-in-jdk-13-part-3-architectures-and-operating-systems?p=606497# https://developers.redhat.com/articles/2021/05/20/shenandoah-garbage-collection-openjdk-16-concurrent-reference-processing?utm_source=chatgpt.com#traditional_reference_processing https://developers.redhat.com/articles/2024/05/28/beginners-guide-shenandoah-garbage-collector?utm_source=chatgpt.com#

jep 404 - generational Shenandoah

ZGC

[논문] Deep Dive into ZGC: A Modern Garbage Collector in OpenJDK - Albert Mingkun Yang.. 기본 개념 설명 여기서 보는게 제일 좋음 https://dl.acm.org/doi/full/10.1145/3538532

Naver D2 개념 설명. 2등. 같이 보기. https://d2.naver.com/helloworld/0128759#ch1-3

https://www.blog-dreamus.com/post/zgc%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C

https://dev.java/learn/jvm/tool/garbage-collection/zgc-deepdive/

openjdk https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main

ppt 그림자료 좋음 https://www.jfokus.se/jfokus18/preso/ZGC--Low-Latency-GC-for-OpenJDK.pdf https://cr.openjdk.org/~pliden/slides/ZGC-PLMeetup-2019.pdf

jep 333 - A Scalable Low-Latency Garbage Colloector 439 - Generational ZGC 490 - Remove the Non-Generational Mode

세대구분 ZGC https://inside.java/2023/11/28/gen-zgc-explainer/

ZGC Lower Tail Latencies(P99) https://www.morling.dev/blog/lower-java-tail-latencies-with-zgc/

Netflix 세대구분 ZGC 전환 https://netflixtechblog.com/bending-pause-times-to-your-will-with-generational-zgc-256629c9386b

AWS EMR HBase 에서 G1 vs ZGC https://aws.amazon.com/ko/blogs/big-data/improve-amazon-emr-hbase-availability-and-tail-latency-using-generational-zgc/

parallel vs g1 vs zgc : throughput, latency.. https://kstefanj.github.io/2021/11/24/gc-progress-8-17.html

대용량 메모리를 갖춘 멀티프로세서 시스템을 대상으로 합니다. G1은 최소한의 설정으로 높은 처리량을 달성하면서 가비지 컬렉션 일시 중지 시간 목표를 높은 확률로 충족하도록 설계되었습니다. G1은 다음과 같은 특징을 가진 현재의 대상 애플리케이션 및 환경을 사용하여 지연 시간과 처리량 간의 최적의 균형을 제공하는 것을 목표로 합니다. https://docs.oracle.com/en/java/javase/11/gctuning/garbage-first-g1-garbage-collector1.html

• 목표한 짧은 정지 시간을 유지하며 최대한의 처리량을 끌어내는 두가지 목표의 균형
  • 목표 정지 시간을 지정할 수 있고, G1 GC 는 그 시간을 지키려 노력
  • 옵션 조정을 통해 더 높은 처리량 or 짧은 정지 시간 택1의 조정도 가능
• 리전간 복사는 mark-copy, 정리떄에 한 리전으로 모인다는 개념은 mark-compact
• JDK 9부터 기본 컬렉터
• CMS 를 완전히 대체
• Young/Gen 영역용 GC 로 구분되지 않는 GC 이다. G1 GC 는 Young/Old 모두를 처리한다.
  • -XX:+UseG1GC 로 명시적으로 활성화 할 수 있다.

주요 개념

1. 일시 정지 시간 조절 : Young GC 기록을 통해 Young Gen 의 크기를 수정함. GC 에 걸리는 시간이 조절됨.
2. 일시 정지 시간 조절 : Marking 은 Concurrent(SATB)
3. 일시 정지 시간 조절 : CMS 에 비해 Compact 가 있으므로 메모리 단편화 X. Full GC 의 빈도가 낮음.
4. 높은 처리량 : 살아남은 객체를 Copy, Compact 하는 과정(오래 걸리는 작업)은 STW 상태에서 병렬로 실행됨
5. 둘 다
   • Concurrent Marking 단계에서 공간이 큰 Old 영역에 대한 CSet 의 선정을 위한 작업을 동시에 실행하여 일시 정지 시간을 줄임
   • Mixed GC 시 CSet 만 Scan 하여 높은 처리량(짧은 GC 시간)
   • Reclamation Efficiency 기반 GC 로 짧은 시간에 많은 양의 메모리를 정리

CMS 와 다르게 회수 단계에 Mark-Compact 를 사용한다. 객체를 이동시키는 과정에서는 유저 스레드와 동시에 실행하지 않으므로 이론상 CMS 보다는 정지 시간이 길 수 있다. 하지만 최대한 짧은 시간이 목표인 CMS 와 최대의 처리량과 목표한 정지 시간이라는 G1 의 정지 시간 차이는 납득할 만 하며, 실제로 거의 나지 않는다.

Region

• G1 에서 힙을 나누는 단위
  • 기존 Serial 같은 연속된 공간의 세대 구분 레이아웃과 다름
• 크기는 -XX:G1HeapRegionSize 로 설정
  • 설정하지 않는다면 initial 과 max 힙 크기에 따라 달라짐. 힙 내에 2048 개 정도의 region 이 만들어질 수 있는 크기가 셋팅 (크기는 항상 2의 제곱수)
• Region 단위로 메모리를 관리함으로써, 높은 처리량 달성이 가능
  • Region 단위의 메모리 회수 비용 예측(후술)
• 모든 Region은 Eden, Survivor, Old 가 될 수 있으며 동적으로 바뀜

Garbage Collection Cycle

Young GC 와 Concurrent marking 을 진행하는Young-Only Phase 와 Mixed GC 진행하는 Space Reclamation Phase 의 반복

• 그림에서 모든 원은 STW
• 파란색 작은 원 - Young GC
• 빨간색 작은 원 - Mixed GC

Concurrent Marking

https://tschatzl.github.io/2022/08/04/concurrent-marking.html

GC Root 를 마킹하는 단계

SATB 를 만들고, Marking 을 시작하기 위해 Root 를 마킹하는 단계이다. Concurrent Marking 의 시작이며, IHOP 임계점을 넘으면 시작된다.

1. Concurrent Marking Start
   • STW 단계지만, Young GC 의 STW 와 같이 실행하여 STW 최소화.
     • Young GC 에 piggyback 한다. 이 때 승격된 Region 들을 기록한다. 이는 다음 Concurrent Root Region Scan 에서 쓰인다.
   • GC Root 로 부터 직접적인 참조 객체 마킹
   • SATB 생성(TAMS 포인터 셋팅)
2. Concurrent Root Region Scan
   • Start 단계에서 Marking 한 Region 의 객체들을 root 로 취급하여 마킹한다.
   • SATB 스냅샷에 의해 고정되어 있으므로 Region 만 STW 인 첫번째 단계에서 정해주면 이 단계는 Concurrent 하게 처리할 수 있다.

동시 마킹은 Mixed GC 에서 Old Generation 에서 살아있는 객체를 Marking 하는 것이다. Old 영역에서 살아남아야 할 객체는 다음 두가지로, 둘 다 Root 로서 마킹하고 객체 그래프를 순회해야한다.

1. 스택 등 에서 참조중인 객체
2. Young Gen 에서 참조중인 객체

1번은 별 문제가 없는데, 2번은 문제가 있다. Young GC 에서 세대간 참조인 Young Gen <- Old Gen 참조는 RSet 을 통해 쉽게 해결이 가능하지만, Old GC 에서 세대간 참조인 이 경우는 RSet 으로 해결이 불가능하다. 따라서 Young Gen 을 모두 스캔하여 Old Gen 으로의 참조가 있는지 체크해야 한다. 이를 위해 Concurrent Marking Start 는 Young GC 에 얹혀 실행되며 Young GC 의 스캔에 껴서 Old Gen 으로의 참조가 있는 Young Region 을 골라둔다.

Young -> Old 로의 세대간 참조가 RSet 만으로 해결되지 않는다는건.. 이 글에서 참고했는데, 근거는 명확하진 않다. 내 생각으로는 oracle 문서 에서 Young Gen 의 RSet 은 항상 유지하지만, Old Gen 의 RSet 은 lazily 하게 완성되기 때문에 완벽하지 않기 때문이지 않나 싶다. Old Gen 의 RSet 을 lazily 하게 세팅되는 이유는 Old Gen 은 리전이 엄청 큰데 Rset 을 유지하면 메모리가 많이 들어서 그렇다. (이슈)

동시 마킹

3. Concurrent Marking
   • 이전 단계를 통해 Root 객체들은 모두 마킹되어 있음.
   • 비트맵 보고 마킹되어 있으면 거기부터 탐색 시작하여 살아 있는 객체를 마킹.
   • 이 단계 중 TAMS 이하의 객체에 대해 변경 작업이 있으면, SATB Pre-Write-Barrier 로 원래 참조값을 SATB Buffer 에 ADD. 이는 SATB 로 첫 스냅샷 기준으로 Marking 을 진행하기 위해 버퍼에 원래 값을 집어넣어놓고 사용하는 과정이다. 버퍼의 값(원래값)을 꺼내서 마킹하는 식으로 초기 스냅샷 기준 마킹을 진행.
4. Remark
   • STW
   • SATB Buffer 를 drain 하여 marking 마무리.
     • SATB Buffer 에는 변경 전 oops 가 들어있으며, 해당 oops marking 후 객체 그래프 탐색. 이 작업 반복.
   • 클래스 언로딩, 비어있는 Region 회수
   • Garbage 양에 따른 CSet Candidate 선정
   • TARS(Top-At-Rebuild-Start) 포인터를 Top 에 추가
5. Concurrent Rebuild RSet, Scrub Region
   • CSet Candidate 에 속한 Old Gen Region 의 Region Bottom ~ TARS 사이 객체에 대해 cross-region 참조를 찾고 RSet 을 갱신
     • 이는 mixed gc 시 RSet 을 참고하여 GC 를 하기 위해 RSet 을 정비하는 작업
6. Cleanup
   • STW
   • CSet Candidate 을 효율성 및 연결성 순으로 정렬하여 최종 확정
   • CSet 의 상태를 보고 Reclaimation Phase 를 아예 실행하지 않기로 결정할 수도 있음

가비지 컬렉팅

Young GC 와 Mixed GC 둘 다 크게 네가지 단계로 이뤄진다. 다른건 CSet 이 Young Gen Region 이냐, Young Gen Region + Old Gen Region 이냐다.

1. Pre Evacuate Collection Set
   • TLAB 를 유저 스레드에서 해제
   • CSet candidate 에서 CSet 선택
2. During Merge Heap Roots
   • CSet 의 RSet 을 병합. 여러 Region 을 처리할 것이기 때문에 중복을 제거해두기 위해.
3. Evacuate Collection Set
   • 루트 참조로부터 객체 그래프 끝까지 스캔 및 복사/이동
     • 상위에서 참조된 객체는 살아있다는 것이고, 해당 객체를 객체를 복사/이동
     • 이후 해당 객체를 CSet Root 로 삼아서 하위 그래프 스캔
     • 더이상 하위 객체가 없을 때 까지 반복
4. Post Evacuate Collection Set
   • Free CSet 등 정리 작업

Young GC

• 대상은 Eden, Survivor 전체
• Eden 의 객체를 Survivor 로 복사
• Survivor 의 객체를 Old 로 복사
• 죽은 객체는 CSet 에 추가되어 다음 Young GC 또는 Mixed GC 에서 정리

Young GC 에서 일시 정지 시간 목표 달성

최대 일시 정지 시간 설정인 -XX:MaxGCPauseTimeMillis 와 GC 간격인 -XX:GCPauseIntervalMillis 는 일시 정지 시간에 영향을 미칠 수 있다.

이 옵션으로 셋팅된 정지 시간 목표를 달성하기 위해 긴 시간 관찰된 비슷한 크기의 young gen 이 GC 되는데 걸린 시간, GC 과정에서 복사했던 객체의 수, 등등의 정보를 근거로 Young GC 가 끝날 때 마다 Young 영역의 크기를 다시 결정한다.

-XX:G1NewSizePercent=5, -XX:G1MaxNewSizePercent=60 이 두 사이의 값에서 G1 가 동적으로 Young Gen 의 크기를 결정한다. 값은 전체 힙 크기 중 Young Gen 의 비율이다.

이렇게 Young GC 는 Young Gen 의 크기를 매번 조정해가면서 목표한 일시 정지 시간을 맞추는데 노력한다.

Mixed GC

• Space-Reclamation 의 목표는 mixed gc 를 통해 Old 영역의 크기를 줄이는 것
• Mixed GC 는 Reclaimation Phase 에서 N 번으로 나뉘어 실행
  • XX:G1MixedGCCountTarget = 8 : 몇번 실행할지 결정
  • CSet Candidate 개수 / XX:G1MixedGCCountTarget = Mixed GC 에서 대략적으로 정리되는 Region 수
• Young/Old 두 영역 모두의 객체를 대상으로 GC 한다고 해서 Mixed
• Space-Reclamation 가 시작되면 Young Gen 의 크기는 -XX:G1NewSizePercent 값으로 고정.
• 목표 정지 시간을 넘어서지 않는 선에서 CSet 순서대로 회수 Region 선택(마킹 단계에서 회수효율 순으로 정렬됨)
• CSet Candidate 에 포함된 Region 은 Conc Marking 단계에서 -XX:G1MixedGCLiveThresholdPercent=85 옵션으로 필터링 되어 있는 상태. 즉, 15% 이상이 죽은 객체인 리전만 들어 있고, 그게 GC 대상 Region.
• XX:G1HeapWastePercent=5 : space-reclamation 를 종료하는 트리거. 전체 힙 크기 대비 CSet 에 남은 미회수 공간 크기의 합의 비율이 이 값보다 낮다면 space-reclamation 를 중지. 쉽게 말하면, CSet 에 정리할 공간이 적게 남았다면 끝낸다.

Tams

• Bottom ~ prev Tams : 이전 Marking 에서 확정된 Bitmap
• prev Tams ~ next Tams : 이전 Marking 시작단계 ~ 현재 Marking 시작단계 까지 새로 생긴 객체들.
  • bottom ~ prev Tams 구간과 함깨 현재 marking 단계의 마킹 대상이 된다. (현재 마킹 이후는 Bottom ~ next Tams 까지의 비트맵이 생긴다)
• next Tams ~ end : 이번 marking 단계 중 새로 생긴 객체들. alive 상태로 간주. 마킹 단계에서는 현재 리전에 대한 마킹과 이전 리전 마킹 기록 efficency 계산이 동시에 이뤄진다. 따라서 두개의 포인터를 두고, 이전 마킹 단계에서 비트맵이 확정 된 곳이 어디까지인가의 저장과, 현재 마킹 단계 시작 이후 생긴 객체들은 어디부터인가를 같이 저장해야한다. 단 이건 jdk20 에서 방식이 바뀌었다. 비트맵에는 마킹 여부를 표시. 이후 객체 생사를 판단하고, 살아있는 객체가 얼마나인가(회수 가능한 객체가 얼마나인가) 판단에 쓰임.

write barrier

1. RSet Card Marking Write Barrier(post write barrier) : 객체 참조 변경시 Rset 의 변경을 큐에 넣는 베리어. 한꺼번에 처리하기 위해 큐에 넣음.
2. Concurrent Marking SATB Write Barrier(pre write barrier) : SATB 동작에서 객체 참조 변경(삭제)시 old ref(이전 값) 을 보존하기 위해 SATB Buffer 에 저장하는 베리어

기억집합(RSet)

https://www.alibabacloud.com/blog/a-detailed-explanation-of-jvm-garbage-collector-g1%26zgc_601536

기존의 Serial GC 에서의 Card Table 은 Old Gen 의 크기를 일정 크기 Page 로 나눈 뒤 해당 영역에 대한 Dirty Check 만 하는 Byte Array 이다. 이는 Young Gen 하나 Old Gen 하나의 구조이기 때문에 가능했다. Young Gen 에서 Dirty 표시를 하면 참조하고 있는 대상인 비회수영역은 Old Gen 하나밖에 없다는 말이다.

하지만 Region 여러개로 나뉜 G1 GC 에서는, 회수 대상 Region 의 객체를 참조하는 비회수 대상 Region 이 여러개일 수 있다. 따라서 G1 에서는 리전간 참조를 기억하기 위해 Remember Set(RSet) 이라는 새로운 구조를 만들어 사용한다. G1 은 기존과 같이 (기본적으로 힙을 512 byte 단위로 나눠서) Card Table 을 관리한다. 다만 Region 마다 존재한다. RSet 은 카드 테이블에 dirty 된 영역이 어떤 외부 Region 으로부터의 참조 때문인지를 인덱스로 관리하는 것이다.

G1 은 Young-Only Phase 에서 Young Gen 에 있는 객체만 정리한다. 이 때 Old Gen Region 에서 참조하고 있는 객체는 정리하면 안된다. 또한 살아남은 객체를 복사 및 이동시에 Old Gen 의 참조를 변경시켜줘야 한다. 이럴 때를 위해 기억집합이 존재한다.

Mutate Thread(유저 스레드) 는 객체의 포인터를 변경(살아남은 객체 이동 등)시에 Post Write Barrier 로 Card Table 에 Dirty 표시를 하고, 해당 사실을 Log Buffer 에 저장한다. Concurrent Refinement Threads 는 버퍼에서 Log 를 꺼내 RSet 을 업데이트한다. 이런 지연된 구조는 한꺼번에 RSet 을 처리하여 효율을 높이기 위해서다.

Concurrent Marking 단계에서 RSet 을 최신화 시키는 단계가 있다. 가비지 컬렉션의 Merge Heap Roots 단계에서는 중복을 제거하기 위해 리전당 RSet 으로 부터 Global RSet 를 만드는 단계가 있다. RSet 은 리전마다 저장하므로 메모리 소비가 G1 내부에서 큰 편이다. 특히 Young Gen 의 크기를 작게 설정할 수록 그만큼 Old Gen 으로 승격되는 객체가 많아져 RSet 의 크기가 커질 수 있음을 유의하자.

CSet

CSet 은 정리 및 복사(Evacuate) 할 대상 Region 의 집합. CSet 은 GC 의 Pre Evacuate Collection 단계에서 정해진다.

Young GC : Young Gen 의 전체가 CSet 이 된다. Mixed GC : Young Gen 전체 + Concurrent Marking 의 결과로 Mixed GC 의 pre-evacuation. 에서 만든 것.

Young GC 는 전체 Young Gen 이 CSet 이기 때문에 고르고 뭐고 하는 과정은 없다.

Mixed GC 에서 사용할 CSet 은 다음과 같이 정해진다. [참고] [참고]

1. Concurrent Marking의 Remark 에서 점유율이 낮은 영역, 즉 여유 공간이 많은 영역을 선택하여 CSet Candidate 을 선정.
2. Concurrent Marking 의 Clean Up 에서 CSet Region 의 점유율과 연결성을 고려하여 GC 효율 순으로 정렬하여 최종 CSet Candidate 를 만듦. (Refine)
3. Mixed GC 에서는 이 정렬된 CSet Candidate 중 N 개의 CSet 을 선택하여 정리. Mixed GC 는 Space Reclaimation 단계에서 여러번 실행될 수 있으며, 각각의 GC 에서 CSet Candidate 중 CSet 를 선택.

IHOP

Recaimation Phase 로 넘어가기 위해 Young-Only Phase 에서 Concurrent Marking 을 시작할 임계점. -XX:InitiatingHeapOccupancyPercent=45 로 셋팅할 수 있다. G1 은 Adaptive IHOP 기능을 지원한다. 처음 두세번의 Concurrent Marking 시작 임계점은 -XX:InitiatingHeapOccupancyPercent=45 으로 하되, 몇번의 GC Cycle 로 정보가 쌓인 후에는 처리량과 정지 시간에 알맞은 IHOP 를 자동으로 정해준다. -XX:+G1UseAdaptiveIHOP 로 켤 수 있다.

이렇게 G1 GC 가 자동으로 현재 상태에 맞게 자원이나 옵션을 자동으로 변경하는 것을 Ergonomic 이라 한다.

주기적 가비지 컬렉팅

운영체제에 힙을 할당/반환하는 과정은 동시 마킹의 Remark 또는 Full GC 의 STW 상태에서만 진행한다.

하지만 G1 은 Full GC 를 최대한 피하는 방식으로 설계되었고, 애플리케이션이 유휴상태라 새로운 객체가 생성되지 않아 동시 마킹이 시작되는 임계값(IHOP) 을 넘지 못한다면 운영체제에 반환할 수 있는 Heap 메모리가 있다 하더라도 반환하지 못하게 될 수 있다. 이런 현상은 On-Demand Cloud 환경에서 비용적으로 불리할 수 있다.

-XX:G1PeriodicGCInterval -XX:G1PeriodicGCSystemLoadThreshold

거대 객체

리전의 크기의 반 이상 크기인 객체를 거대 객체(Humongous Objects )라 한다. 거대 객체는 Old Gen 의 연속된 리전인 거대 리전에 저장된다. 만약 1.5개 리전의 크기의 객체라면 2개의 리전을 차지하며 나머지 0.5 Region 은 쓰이지 않는다.

이러한 거대 객체는 Concurrent Marking 의 CleanUp 또는 Full GC 에서만 Reclaim 될 수 있다. 다만 기본타입 거대 객체의 경우 GC Pause 도중 회수할 수 있다.

거대 리전은 연속된 거대한 Region 을 필요로 하기 때문에 Full GC 를 발생시킬 확률이 있다. 또한 거대 객체는 Full GC 중에도 Compaction 을 위해 이동되지 않는다. 따라서 거대 객체가 많아지면 파편화가 심해져 메모리 부족 오류를 만날 수 있다. 더욱이, 메모리 공간이 충분하더라도 연속된 공간을 찾지 못해 객체 할당 실패 오류를 겪을 가능성도 있다. 이럴때는 Region Size 를 늘려 Region 이 수용할 수 있는 크기를 늘리거나, 힙 자체를 늘리는 방법 밖에 없다.

gc+heap=info 옵션에서 거대 객체의 개수를 알 수 있다.

SATB

SATB 는 marking 을 위한 객체 그래프 스캐닝 중 유저 스레드에 의해 참조 삭제가 일어날 경우 그 사실을 기록한 후 나중에 적용한다. 즉, 마킹 시작시에 살아있던 객체는 끝까지 살아있는 것으로 간주한다.

mutator thread 가 만약 A.a = b 인 상태에서 A.a = c 로 참조 변경을 했다고 치자. 이 때 A.a -> b 로의 참조는 사라지게 되는 것이다. 이 때 Pre Write Barrier 가 동작하여 기존 A.a 에 들어있던 b 참조를 SATB Buffer 에 저장한다.

이후 SATB Buffer 에 있던 참조(b) 는 marking 단계에서 GC Root 로 등록된다.

A.a -> b 의 참조가 사라진 것인데, SATB Buffer 에는 b 값만 저장해도 될까? 어디서 온 참조인지는 저장하지 않아도 될까? SATB 의 목적은 '시작단계에 살아있던건 살아있다 간주' 이기 때문에, 삭제 대상이던 b 가 살아있도록만 만들어주면 된다. b 를 GC Root 로 등록하면 b 부터 시작하여 하위의 참조 객체들이 다 살아남을 수 있다. 그렇기 때문에 SATB Buffer 에는 b 만 넣으면 된다.

SATB 는 같은 문제를 해결하는 incremental-update 방식에 비해 일시 정지 시간을 줄여줄 수 있다. Marking 과 동시에 수정되는 객체 참조의 유형은 대부분이 새로운 객체의 생성이기 때문이다. 삭제된 객체만 관심을 가지는 SATB 방식이 새로운 참조에 관심을 가지는 incremental-update 보다 할일이 적다. [참고 : Compile-Time Concurrent Marking Write Barrier Removal]

SATB 의 단점도 있다. Concurrent Marking 의 초기 단계에서 SATB 를 확정하면 이후 Marking 이나 Mixed GC 는 모두 시작단계 스냅샷 기준으로 동작한다. 즉, SATB 직후에 죽은 객체가 있더라도 다음 사이클이 도래하여 SATB 를 다시 찍기 전에는 죽은걸로 인식되지 않는다. 이런 객체를 부유 쓰레기(floating garbage. 실제로 죽었는데 살아있는것 처럼 보여 회수되지 못함) 라 하며, 메모리 사용량을 높게 한다.

Full GC

Old Gen 의 힙 점유율이 높아 객체를 할당하지 못하면 Full GC 가 발생한다. 특히 거대 객체를 할당할 때 발생할 수 있다.

• 애플리케이션이 회수할 수 없을 정도로 너무 많은 객체를 할당할 경우
  • Concurrent Marking 이 진행중일 때 계속해서 객체가 쌓이면 Mixed GC 에서 Old Gen 의 객체를 정리하기 전에 Full GC 가 발생해버릴 수 있음.
• 거대 객체를 할당하는데 연속된 메모리 공간을 찾지 못할 경우

이러한 Full GC 는 긴 STW 를 발생시켜서, 최대한 줄이는 노력을 해야한다. GC Log 에 Pause Full (Allocation Failure) 로 표시된다.

FUll GC 를 줄이기 위한 방법은 다음과 같다.

1. 거대 객체를 확인하고 리전 사이즈 늘리기
2. 힙 사이즈 늘리기
3. -XX:ConcGCThreads 로 동시 처리 스레드 늘리기
4. IHOP 수정으로 동시 마킹 더 빠르게 하기

Adaptive Option

G1 에는 Ergonomic 이라는 애플리케이션이 실행되며 자동으로 수정되는 값들이 있다. 이를 알아두면 좋을 것.

https://docs.oracle.com/en/java/javase/17/gctuning/garbage-first-g1-garbage-collector1`Ergonomic` 이라는 .html#GUID-082C967F-2DAC-4B59-8A81-0CEC6EEB9016

실제로 보기 옵션

-XX:+UseG1GC -XX:G1HeapRegionSize=1m -XX:InitiatingHeapOccupancyPercent=20 -XX:MaxGCPauseMillis=50 -Xlog:gc*=debug Mixed GC 가 일어날 수 있게 Concurrent Marking 이 발생하는 임계값을 좀 낮춰준다. -Xlog:gc 에는 ergo, heap, age... 많은 태그를 같이 쓸 수 있는데, 모두 볼 수 있게 * 와 레벨을 debug 로 해줄 수 있다.

참고

마킹 전체 내용 - https://tschatzl.github.io/2022/08/04/concurrent-marking.html 전체 내용 잘 설명 - https://www.alibabacloud.com/blog/a-detailed-explanation-of-jvm-garbage-collector-g1%26zgc_601536 oracle 문서, 버전마다 조금씩 다르다 - https://docs.oracle.com/en/java/javase/21/gctuning/garbage-first-g1-garbage-collector1.html#GUID-572C9203-AB27-46F1-9D33-42BA4F3C6BF3 redhat. GC 과정에 전체 리전이 어떻게 변화하는지 그림이 잘되어 있음 - https://www.redhat.com/en/blog/part-1-introduction-g1-garbage-collector redhat. jdk8 기준으로 로그 보면서 설명. - https://www.redhat.com/en/blog/collecting-and-reading-g1-garbage-collector-logs-part-2

G1 논문. 기본적인 아이디어가 거의 다 설명되어 있음 - Garbage-First Garbage Collection. David Detlefs..

jdk20 bitmap 관련 변경. 이런 식으로 메모리 사용량이 줄고 있음. - https://github.com/openjdk/jdk/pull/8957

활동의 거의 없는 애플리케이션의 주기적 GC JEP - https://openjdk.org/jeps/346

RSet, Write Barrier 등 - https://www.jfokus.se/jfokus17/preso/Write-Barriers-in-Garbage-First-Garbage-Collector.pdf

그 외

1. https://www.oracle.com/technical-resources/articles/java/g1gc.html#Taming
2. https://tschatzl.github.io/2025/02/21/new-write-barriers.html
3. https://tschatzl.github.io/2021/02/26/early-prune.html

CMS 는 가비지 컬렉션 일시 중지 시간을 최소화하고, 애플리케이션 실행 중에 가비지 컬렉터와 프로세서 리소스를 공유할 수 있는 애플리케이션을 위해 설계되었습니다. 일반적으로 장기간 보존되는 데이터(tenured 크기가 큰 경우)가 비교적 많고 프로세서가 두 개 이상인 시스템에서 실행되는 애플리케이션은 이 컬렉터를 사용하면 이점을 얻을 수 있습니다. 하지만 일시 중지 시간이 짧은 모든 애플리케이션에 이 컬렉터를 고려해 볼 수 있습니다. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html

CMS 는 STW 에 의한 정지 시간을 최소화시키는 컬렉터다. Concurrent-Mark-Sweep 의 약자다. STW 정지 시간을 최소화하는 방법이 뭘까. 이름에서 힌트를 얻자면 '동시에' 한다는 것이다.

Garbage Collection 단계에서 STW 를 일으키는 단계는 크게 두가지다.

1. Marking : 살아있는 객체를 마킹하는 과정에서 객체 그래프가 변경되면 안된다.
2. Compact : 살아남은 객체의 메모리 파편화를 막기 위해 한 곳으로 모으는 과정이다. 객체의 위치를 옮겨야 하므로 애플리케이션을 멈추고 진행한다.

CMS 는 꼭 필요한 부분을 남기고 많은 부분을 STW 없이 유저 스레드와 동시에 진행하는 방법으로 일시 정지 시간을 줄였다.

CMS 특징

• Old Gen 용 GC.
  • -XX:+UseConcMarkSweepGC 로 활성화. Young Gen GC 는 ParNew 가 사용된.
• Mark-Sweep 알고리즘 기반
• JDK 14 부터는 없어져 사용할 수 없음
  • 대체제는 G1 GC
• 지연 시간 최소화 컬렉터라 서버용 빠른 응답을 하기에 적절하다.

없어진걸 왜 알아야 하나..

서버용 JVM 은 지연 시간을 줄이는 목표로 발전했다. 최근의 그러한 Garbage Collector 가 ZGC 이다.

지연 시간을 줄이는데 가장 크게 발목 잡는 것이 STW 이고, STW 를 줄이는 방법은 객체의 생성/삭제/이동을 유저 스레드의 동작과 안전하게 같이 진행하는 것이다.

CMS 이전의 GC(Serial, ParNew, PS..) 는 GC 모든 과정에서 STW 를 하였다. CMS 는 유저 스레드와 GC 의 일부를 동시에 실행시킨 첫 GC 로서 의미가 있으며, 어떻게 그렇게 했는지를 이해하면면 CMS 이후에 나온 GC 를 이해하기 더 쉽다.

Garbage Collection 중 동시에 실행하는 것

1. GC Root 로 부터 참조 체인을 따라가면서 Marking 하는 작업
2. Sweep

Marking 단계중 CMS 가 유저 스레드와 동시에 실행하는 작업은 GC Root 로 부터 참조 체인을 따라가며 살아있는 객체에 마킹하는 작업이다. 루트 노드를 열거하는 작업은 여전히 STW 로 실행된다.

그러나 루트 노드 열거보다 참조 체인을 따라가는 작업이 훨씬 오래 걸리기에, 의미있는 발전이다.

또한 Compact 가 아닌 Sweep 이라서, 죽은 객체를 회수(Sweep)하는 작업을 유저 스레드와 동시에 진행할 수 있었다.

동작 방식

1. 최초 Marking

STW 루트 노드와 직접 연결된 객체만 mark 한다. 빠르게 끝남.

2. 동시 Marking

NO-STW 루트 노드와 직접 연결된 객체로 부터 객체 그래프를 탐색하며 mark 한다. 새로 생긴 객체는 증분 업데이트 방식에 따라 따로 기록해둔다.

3. Re-Marking

STW. 증분 업데이트 방식에 의해 따로 기록한 객체를 반영한 mark 를 진행한다. 최초 표시보다 정지가 조금 더 길지만, 여전히 짧은 시간이다.

4. 동시 Sweep

NO STW 유저 스레드가 실행되는 것과 동시에 죽은 객체를 회수한다.

CMS 의 단점

1. 프로세서 자원에 민감

유저 스레드와 동시에 GC 를 실행한다는 것은 하나의 시간에 CPU 처리량을 GC 가 뺏어간다는 이야기다. CMS 는 (프로세서 코어 수 + 3)/4 개의 스레드 로 GC 를 진행한다. 프로세서 코어 수가 적으면 적을수록 GC 가 사용하는 자원의 비용이 커진다.

따라서 Oracle 문서 에서도 프로세서가 2개 이상인 환경에서 적합하다고 명시되어 있다.

2. 동시 모드 실패

CMS 는 유저 스레드와 동시에 실행된다. 따라서 Old Gen 의 공간이 100% 찼을때 GC 를 하면 안된다. 동시에 실행되는 스레드에 의해 만들어질 객체가 할당될 공간이 필요하기 때문이다.

특히 동시에 실행되는 유저 코드에 의해 한 객체가 죽었다 하더라도, 그 시점이 CMS 의 Marking 단계가 끝난 직후라면 다음 GC 까지 기다려야 한다. 이런 객체를 부유 쓰레기라 한다.

-XX:CMSInitiatingOccupancyFraction 옵션은 Old Gen 이 몇 % 차야 CMS GC 가 실행될지 설정할 수 있다. JDK6 부터 기본값은 92% 이다. Old Gen 의 여유 공간이 8% 남게 되면 CMS GC 가 시작된다.

만약 8% 남은 상태에서 더 큰 공간의 할당 요청이 오면? 이 상황을 동시 모드 실패 라고 하며, CMS 는 애플리케이션을 멈추고 Serial Old GC 로 Major GC 를 실행한다. 이 동작은 매우 느리기 때문에 -XX:CMSInitiatingOccupancyFraction 옵션을 잘 조정하는게 중요하다.

3. 메모리 파편화

mark-sweep 알고리즘의 한계이다. CMS 역시 직면해야하는 문제다. 메모리 파편화가 심해지면 전체 GC 를 실행해야 한다.

JDK 8 까지는 Foreground Collection 이라고 해서 -XX:+UseCMSCompactAtFullCollection, -XX:+UseCMSCompactAtFullCollection 옵션을 활용하여 Full GC 전 Compact 를 하여 파편화로 인한 메모리 부족을 해결할 수 있었다.

하지만 JDK-8010202에서 Foreground Collection 은 전체 GC 보다 더 오래 걸리고 문제가 많아서 JEP-214 에 의해 JDK9 부터는 사라졌다.

그래서 메모리 파편화는 결국 CMS 에서 근본적 문제로 남게 되었다.

Garbage Collector 의 성능은 처리량(Throughput), 지연 시간(Latency), 메모리 사용량(footprint) 세가지 요소로 측정된다. 이 세가지는 모두 만족시키기 어렵다.

Garbage Collector 를 알아볼때에는 각 컬렉터들이 어떤 성능을 중요시하는지 알고 보는게 좋다.

지연 시간

지연 시간은 여러 요소에 의해 바뀌겠지만, Garbage Collector 관점에서는 일시 정지 시간과 관련이 많다. Stop-The-World 라고 하는 일시 정지 시간은 죽은 객체를 판별(mark)하거나, 살아남은 객체를 모으는(compact) 과정에서 필요하다.

이 STW 는 애플리케이션 전체를 멈추게 하기 때문에 P99, P999 같이 튀는 latency 를 유발할 수 있다. 멈춰있는 시간이 길수록, 그 사이에 해야 할 일이 많이 쌓일수록 요청중 튀는 latency 가 발생할 확률이 높다.

따라서 CMS, 셰넌도어, ZGC 같은 경우는 STW 를 최소한으로 줄이기 위한 방법들로 발전해 왔다. 큰 틀에서는 mark, compact 과정을 유저 스레드와 동시에 실행하는 방법을 각 garbage collector 에서 다르게 구현한다.

지연 시간이 짧은 garbage collector 는 유저 대상으로 하는 서버 애플리케이션에서 적절하다. java 언어가 서버 애플리케이션 개발에서 가장 많이 쓰이기 때문에, 최신의 garbage collector 들은 지연 시간을 최소화 하는 방향으로 진화하고 있다.

처리량

처리량은 위와 같다. 사용자 코드 실행 시간이 99초, GC 시간이 1초라면 처리량은 99% 이다. 한정된 CPU 자원에서 GC 를 위해 스레드가 사용되는 비율이 얼마나 되는가를 수치화 한 것이다. 즉 짧은 GC 시간에 많은 양의 객체를 정리할 수 있는 garbage collector 가 처리량이 좋다고 할 수 있다.

보통 짧은 지연 시간을 추구하면 처리량은 낮아진다.

1. 처리해야 하는 객체는 변하지 않는데 지연 시간을 짧게 목표한다면 한번의 STW 를 짧게 유지해야한다. 그렇게 되면 결국 GC 를 짧게 여러번 호출해야하기 때문에 그만큼 처리량은 낮아진다.
2. 지연 시간을 짧게 하기 위해 유저 스레드와 동시에 GC 를 실행한다고 했다. 그 만큼 유저 스레드가 CPU 자원을 사용한다는 것이므로 처리량이 낮아질 수 있다.

저지연 컬렉터인 ZGC, 셰넌도어의 목표는 지연 시간을 최소로 함과 동시에 G1 에 비해 처리량의 감소가 10% 미만으로 되게끔 하는 것이었다.

처리량이 높은 GC 는 분석 애플리케이션 등 유저와 상호작용이 적은 애플리케이션에 적합하다.

메모리 사용량

세대 구분 이론에 따른 메모리 layout 을 처리하는 Garbage Collector 들은 세대간 참조를 해결하기 위해 카드 테이블을 관리한다. 이 카드 테이블도 Gacbage Collector 마다 재각각이며, 메모리 사용량이 다르다.

또한, 메모리 사용량은 아니지만 Garbage Collector 들은 카드 테이블 관리에 사후 write barrier 를 사용하거나, ZGC 에서 컬러 포인터 구현에 load barrier 를 쓰는 등 여러가지 barrier 를 사용한다. 이는 애플리케이션에 가하는 실행 오버헤드이며 주시해야 하는 footprint 이다.

세대 구분 이론에 따른 알고리즘 선택

https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html G1 GC 이전의 GC(Serial, Parallel, CMS) 들은 모두 위와 같은 메모리 레이아웃에서 동작했다.

weak generational hypothesis 에 따르면 새로 생성되는 객체중 대다수는 빠르게 죽기 때문에 Young Generation 의 GC 는 메모리 파편화를 방지하며 객체가 적을 때 효율적인 Mark-Copy 알고리즘을 사용한다.

반대로 Old Generation 의 GC 는 큰 영역을 청소하기 때문에 오래걸린다. 최대한 많은 양을 저장하여 GC 횟수를 줄이기 위해 크기의 반만 사용할 수 있는 Mark-Copy 대신 Mark-Sweep 또는 Mark-Compact 를 사용하는게 좋다.

초창기의 JDK 에서는 Garbage Collector 들이 Young/Old Gen 각각용으로 만들어졌고 조합을 하여 사용 가능했다. 시간이 지남에 따라 Garbage Collector 를 Young/Old 각각 설정할 수 있는 것이 아닌 하나만 설정하면 최적의 조합으로 셋팅되는 방식으로 하나로 합쳐졌다.

예를 들어 CMS 는 Old Gen 용 Collector 이다. 하지만 JDK9 부터는 CMS 를 사용하면 Young Gen 용 Collector 로서 Parnew 가 자동으로 선택된다.

이런 역사를 알아놓으면 이해하기 한층 편할 것 같다.

GC 뭐쓰는지 알기

1. ManagementFactory.getGarbageCollectorMXBeans()
2. -XX:+PrintGCDetails / -Xlog:gc* (버전에 따라 둘 중 하나)
3. jhsdb jmap --heap --pid [pid]
   • jps 로 pid 얻을 수 있음.

기본적 컬렉터들

Young Generation Garbage Collector

Serial [-XX:+UseSerialGC]

• mark-copy
• 메모리 사용량이 가장 적다.
• 단일코어, 또는 코어가 적은 환경에서 스레드 상호작용이 없으므로 오버헤드가 없다.
• DefNew GC 라고도 한다.

파뉴(ParNew) [-XX:+UseParNewGC]

• mark-copy
• Serial 과 다른점은 GC 를 병렬로 처리한다는 것이다. 하지만 일반적으로 Parallel Collector 라고 부르는 컬렉터는 파뉴가 아니다. 처리량을 목표로 두고 처리량을 옵션으로 조절할 수 있는 PS 컬렉터가 Parallel 컬렉터다.
• JDK8 까지는 default GC 가 Parallel 이며 CMS 가 권장되었다. Old 영역의 CMS 는 Young 영역에 PS 를 조합하지 못하였으므로 파뉴가 대신 많이 쓰였다.
  • -XX:+UseConcMarkSweepGC 로 cms 를 사용하면 기본적으로 -XX:+UseParNewGC 가 켜진다. -XX:-UseParNewGC 옵션을 주면 Serial Collector(DefNew young collector) 가 쓰인다.
• JDK9 부터는 G1 GC 가 default GC 이며 권장된다. -XX:+UseParNewGC 옵션은 사라졌으며, CMS 선택시 파뉴가 Young 영역 컬렉터로 강제된다.
• 싱글스레드 환경에서는 시리얼GC 보다 성능이 떨어진다.
• -XX:ParallelGCThreads 로 GC 스레드 수 제한 가능. CMS 쓸때 가능한 옵션.

페러렐 스캐빈지(PS) [-XX:+UseParallelGC]

• mark-copy
• 처리량을 제어하는게 목표인 컬렉터.
• -XX:MaxGCPauseMillis : 정지 시간이 이 시간이 넘지 않도록 노력한다. 이 시간이 너무 적으면 Young 영역의 크기가 적게 할당되어 오히려 처리량이 떨어질 수 있다.
• -XX:GCTimeRatio : GC 시간이 1% 이상이 되지 않도록 보장. 기본값은 99.
• -XX:+UseAdaptiveSizePolicy : 가상머신이 성능 모니터링 정보를 수집하여 최적의 정지 시간과 처리량을 보장하기 위해 -Xmn, -XX:SurvivorRatio 같은 값들을 자동 조정해준다.
  • -XX:MaxGCPauseMillis, -XX:GCTimeRatio 만 설정해주고 JVM 이 설정해주는 값을 모니터링하는것도 좋은 방법.

Old Generation Garbage Collector

시리얼 올드 [-XX:+UseSerialGC]

• mark-compact
• 코어가 적은 환경에서 주로 쓰인다.
• 따로 Old Gen 만 이 컬렉터를 지정하는 옵션은 없다. -XX:+UseSerialGC 로 Young/Gen 모두 시리얼로 동작할 때 쓰이는 MarkSweepCompact GC(이름임) 가 이것이다.

• -XX:+UseParallelGC -XX:-UseParallelOldGC 이렇게 옵션을 주면 Old 영역에 PS MarkSweep 가비지 컬렉터가 쓰인다.
  • PS Mark Sweep GC 는 아래 페러렐 올드에서 쓰이는 병렬 버전과, 지금 설명에서의 조합에서 쓰이는 Serial 버전이 있다.
  • -XX:+PrintGCDetails 로 Old Gen 이름을 보면 -XX:+UseParallelOldGC 는 ParOldGen, -XX:-UseParallelOldGC 는 PSOldGen 으로 표시되는걸 볼 수 있다.
  • JEP-366 에서 JDK 14 에 이 조합은 폐기대상이 되었고, 15 부터는 UseParallelOldGC 옵션 자체가 없어졌다.

• cms 의 동시 모드 실패시 백업용 컬렉터로도 Serial Old 가 쓰일 수 있다.

페러렐 올드 [-XX:+UseParallelOldGC]

• mark-compact
• 멀티스레드로 병렬 회수한다.
• Young Gen PS 의 Old Gen 버전이다. 처리량이 중요하다면 PS + 페러렐 올드 조합을 사용하면 된다.
• Old Gen 을 ParOldGen 으로 관리하는 PS MarkSweep 컬렉터를 사용한다.
• JDK8 의 기본 컬렉터 옵션인 -XX:+UseParallelGC 를 사용하면 Old Gen 에는 이 컬렉터가 자동 선택된다.
• JDK9 이후 기본 컬렉터는 G1 으로 바뀌었다. 이때부턴 -XX:+UseParallelGC 옵션으로 Young Gen 에는 PS, Old Gen 에는 페러렐 올드를 사용한다.
• JDK15 부터는 -XX:+UseParallelOldGC 옵션이 없어졌다.(JEP-366)

참고 https://openjdk.org/jeps/366 https://www.fasterj.com/articles/oraclecollectors1.shtml https://stackoverflow.com/questions/16442934/serial-mark-sweep-compact-psoldgen-ps-stands-for?utm_source=chatgpt.com https://blog.ragozin.info/2011/12/garbage-collection-in-hotspot-jvm.html https://stackoverflow.com/questions/39929758/ps-marksweep-is-which-garbage-collector