JVM

Huisu·2024년 7월 22일

ETC

목록 보기

5/6

JVM의 동작 방식

Java의 가장 큰 특징 중 하나는 Write Once Run Anywhere이다. 즉 한 번 쓰면 어디서든 실행 가능하도록 하는 것이다. 하지만 우리가 사용하는 컴퓨터는 CPU마다 받아들이는 기계어가 다르다는 문제점을 가진다. Java는 이러한 문제점을 해결하기 위해 JVM이라는 가상 머신을 띄워서 프로그램을 실행시킨다. JVM은 자바에서만 사용하는 것은 아니다. C++을 Java Bytecode로 번역해서 JVM 위에서 실행시키는 Kotlin 등을 예시로 들 수 있다. 그렇다면 JVM의 동작 방식은 어떻게 될까?

자바 프로그램을 실행하면 JVM은 OS로부터 메모리를 할당받는다.
자바 컴파일러인 javac가 자바 소스 코드인 .java를 자바 바이트 코드인 .class로 컴파일한다.
Class Loader는 동적 로딩을 통해 필요한 클래스들을 로딩 및 링크하여 Runtime Data Area (실질적인 메모리를 할당받아 관리하는 영역)에 올린다.
Runtime Data Area에 로딩된 바이트 코드는 Execuation Engine을 통해 해석된다.
이 과정에서 Execuation Engine에 의해 Garbage Collector의 작동과 Thread 동기화가 이루어진다.

JVM의 구조

그렇다면 JVM의 구조를 더 상세하게 살펴 보자.

클래스 로더 (Class Loader)
실행 엔진 (Execuation Engine)
- 인터프리터 (Interpreter)
- JIT 컴파일러 (Just-in-Time)
- 가비지 콜렉터 (Garbage Collector)
런타임 데이터 영역 (Runtime Data Area)
- 메소드
- 힙
- PC Register
- 스택 (static)
- 네이티브 메소드
JNI - 네이티브 메소드 인터페이스
네이티브 메소드 라이브러리

Class Loader

자바 컴파일러를 통해 .class 확장자를 가지게 된 클래스 파일들은 각 디렉터리에 흩어져 있다. 또한 기본적인 라이브러리의 클래스 파일들도 $JAVAHOME_ 내부 경로에 존재한다. 이렇게 흩어져 있는 각각의 클래스 파일들을 찾아서 동적 로딩 방식으로 런타임 데이터 영역인 JVM 메모리에 탑재해 주는 역할을 한다.

클래스 로더는 크게 Loading, Linking, Initializing 세 단계를 거치며, 중에서도 Linking 과정은 Verifying, Preparing, Resolving 과정을 거친다.

Loading: 클래스 파일을 가져와서 JVM의 메모리에 로드한다.
Linking: 클래스 파일을 사용하기 위해 검증하는 과정이다.
- Verifying: 읽어들인 클래스가 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.
- Preparing: 클래스가 필요로 하는 메모리를 할당한다.
- Resolving: 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다.
Initialization: 클래스 변수들을 적절한 값으로 초기화 (static 필드들을 설정된 값으로 초기화)

Execution Engine

실행 엔진은 런타임 데이터 영역에 할당된 데이터를 읽어 바이트 코드의 명령을 한 줄씩 실행한다. 자바 바이트 코드 (.class)는 기계가 바로 수행할 수 있는 언어보다는 가상 머신이 이해할 수 있는 중간 레벨로 컴파일된 코드이다. 따라서 기계가 바로 수행할 수 없다. 실행 엔진은 이러한 바이트 코드를 실제로 JVM 내부에서 기계가 실행할 수 있는 형태로 변경한다. 이 수행 과정에서 인터프리터와 JIT 컴파일러 두 가지 방식을 혼합하여 바이트 코드를 실행한다.

Interpreter

바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행한다. JVM 안에서 바이트코드는 기본적으로 인터프리터 방식으로 동작한다. 다만 같은 메소드라도 여러 번 호출이 된다면 매번 해석하고 수행해야 해서 전체적인 속도는 느리다.

Just-In-Time Compiler (JIT)

이러한 인터프리터의 단점을 보완하기 위해 도입된 방식이다. 반복되는 코드를 발견하여 바이트 코드 전체를 컴파일한 후 Native Code로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅하지 않고 캐싱해 두었다가 네이티브 코드로 직접 실행하는 방식이다.

한 번 캐싱된 메소드는 다시 호출되었을 경우 또 해석하지 않고 캐싱해 둔 네이티브 코드를 직접 실행하는 것이다. 따라서 인터프리팅 방식보다 빠르다.

하지만 바이트 코드 전체를 네이티브 코드로 변환하는 데에는 많은 비용이 소요되기 때문에, JVM은 모든 코드를 JIT 방식으로 실행하지 않고 인터프리터 방식을 사용하다가 일정 수준이 넘어가면 JIP 컴파일 방식으로 명령어를 실행한다.

Garbage Collector (GC)

Heap 메모리 영역에서 더는 사용하지 않는 메모리를 자동으로 회수해 주는 기능을 제공한다. 개발자가 직접 메모리를 해제해야 하는 C랑 다르게 Java는 이 기능을 가비지 컬렉터가 자동으로 실행해 주며 실시간으로 최적화시켜 준다. 가비지 컬렉터가 정확하게 어떤 방식으로 작동하는지는 정해져 있지 않다. 특히 Full GC가 발생한 경우 GC를 제외한 모든 스레드가 중지되기 때문에 큰 장애가 발생할 수도 있다.

수동으로 GC를 실행하기 위해 System.gc() 라는 메소드를 사용할 수 있지만, 함수 실제 실행은 보장되지 않는다.

Runtime Data Area

JVM은 프로그램 실행에 사용되는 메모리를 런타임 데이터 영역이라고 부르는 몇 가지 영역으로 나눠서 관리한다.

JVM 단위에 속하는 힙과 메서드 영역은 JVM과 수명 주기를 같게 가진다. JVM 당 하나씩 영역이 생성된다. 따라서 모든 스레드는 동일한 힙 영역과 메서드 영역을 공유한다.

클래스 단위에 속하는 런타임 상수 풀은 클래스와 수명 주기를 같게 한다. 따라서 클래스 하나에 런타임 상수 풀도 하나가 생성된다.

스레드 단위에 속하는 PC 레지스터, JVM 스택, 네이티브 메서드 스택은 스레드와 수명 주기를 같게 한다. 이들 역시도 스레드 당 하나씩 생성된다.

Method Area

Method Area는 JVM이 시작할 때 생성되는 공간으로, 바이트 코드 (.class)를 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간이다. JVM이 동작하고 클래스가 로드될 때 적재돼서 프로그램이 종료될 때까지 저장된다. 에는 인스턴스 생성을 위한 객체 구조, 생성자, 필드 등이 저장됩니다. 런타임 상수 풀과 정적 변수, 그리고 메서드 데이터와 같은 클래스 데이터들도 여기에서 관리한다. 이 영역은 JVM 당 하나만 생성되는데, 인스턴스 생성에 필요한 정보도 존재하기 때문에 JVM의 모든 스레드들이 Method Area를 공유하게 된다.

Heap Area

힙영역은 메서드 영역과 함께 모든 쓰레드가 공유하며, JVM이 관리하는 프로그램 상에서 데이터를 저장하기 위해 런타임 시 동적으로 할당하여 사용하는 영역이다. 즉 new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타입 등 Reference Type이 저장되는 곳이다. 이 곳이 가득 차게 되면 OutOfmemoryError를 발생시키게 된다.

힙 영역에 생성된 객체와 배열 같은 Reference Type은 JVM의 스택 영역의 변수나 다른 객체의 필드에서 참조된다. 즉, 힙의 참조 주소는 스택이 가지고 있고, 해당 객체를 통해서만 힙 영역에 있는 인스턴스를 핸들링할 수 있다.

만약 힙 영역에 있는 인스턴스를 참조하는 변수나 필드가 없다면 의미 없는 객체로 취급하고 가비지 컬렉션의 대상이 된다. 가비지 컬렉션을 수행하기 위해서는 아래와 같이 다섯 개의 영역으로 나뉘는데, 보통 Young Generation에 생명 주기가 짧은 객체를 대상으로 관리하고, Old Generation에 생명 주기가 긴 객체를 대상으로 관리한다.

Stack Area

스택 영역은 int, long, boolean 등 기본 자료형을 생성할 때 저장되는 공간으로 임시적으로 사용되는 변수나 정보들이 저장되는 영역이다. 마지막에 나온 값이 멈ㄴ저 나가는 LIFO 구조로 push와 pop 기능 사용 방식으로 동작한다. 메서드 호출 때마다 각각의 스택 프레임 (그 메서드만을 위한 공간)이 생성되고, 호출된 메서드의 매개변수, 지역 변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장한다. 그리고 메서드 수행이 끝나면 프레임별로 삭제된다.

스택 영역은 각 스레드마다 하나씩 존재하며 스레드가 시작될 때 할당된다. 프로세스가 메모리에 로드될 때 스택 사이즈가 고정되어 있어 런타임 시에 스택 사이즈를 바꿀 수는 없다. 고정된 크기의 JVM 스택에서 프로그램 실행 중 메모리 크기가 충분하지 않다면 StackOverFlowError가 발생하게 된다.

전체적인 그림은 다음과 같다.

Program Counter Register

PC 레지스터는 스레드가 시작될 때 생성되며, 현재 수행 중인 JVM 명령어 주소를 저장하는 공간이다. JVM 명령의 주소는 스레드가 어떤 부분을 무슨 명령으로 실행해야 할지에 대한 기록을 가지고 있다. 일반적으로 프로그램의 실행은 CPU에서 명령어를 수행하는 과정으로 이루어진다. 명령어 수행 중 중간에 일어나는 중간값이나 기억해야 할 값들을 가지고 있는 부분이다.

하지만 자바의 PC Regisger는 CPU Register와 다르다. 자바는 OS나 CPU 입장에서는 하나의 프로세스이기 때문에 가상 머신의 리소스를 이용해야 한다. 그래서 자바는 CPU에 직접 연산을 수행하도록 하는 것이 아닌, 현재 작업하는 내용을 CPU에게 연산으로 제공해야 하며, 이를 위한 버퍼 공간으로 활용하는 것이 PC Register이다.

스레드가 자바 메소드를 수행하고 있으면 JVM 명령의 주소를 PC Register에 저장하고 자바가 아닌 다른 언어의 메소드를 수행하고 있으면 undefined 상태가 된다. 자바에서는 이 두 부분을 따로 처리하기 때문이다.

Native Method Stack

네이티브 메서드 스택은 자바 코드가 컴파일되어 생성되는 바이트 코드가 아닌 실제 실행할 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다. 또한 자바 이외의 언어 (C, C++, 어셈블리어) 등으로 작성된 네이티브 코드를 실행시키기 위한 공간이기도 하다. JIT 컴파일러로 인해 변환된 코드도 여기서 실행된다.