[Java] JVM이란? - (3) 구성 요소

지난 1편, 2편에 이어 마지막 3편이다.

 

JVM이 어떻게 구성되어 있는지에 대해 알아본다.

 

이번 글도 역시 여기와 여기를 참고하며 작성하였다.

 

---

 

JVM의 구성요소

자바 애플리케이션을 실행하기 위해 JVM은 자바 클래스 로더(Class Loader)와 자바 실행 엔진(Execution Engine)에 의존한다.

 

자세히 알아보기 전에 이전 글에서 보았던 그림을 다시 가져와 보자.

출처) https://asfirstalways.tistory.com/158

 

JVM 자바 클래스 로더 (Class Loader)

자바에서는 모든 것이 클래스이며, 모든 자바 애플리케이션은 그러한 클래스로부터 만들어진다.

즉, 하나의 애플리케이션이 하나 또는 수천 개의 클래스로 구성될 수 있다는 말이다.

 

그러한 자바 애플리케이션을 실행하기 위해서는 컴파일된 .class 파일을 JVM 내로 로드(Load)하고 링크를 통해 배치해야 한다.

클래스 로더가 그런 기능을 수행하는 JVM의 구성 요소이기 때문에 모든 JVM에는 클래스 로더가 포함되어 있다. 자바 클래스 로더는 Runtime 시에 동적으로 클래스를 메모리에 로딩하며, 사용하지 않는 클래스들은 메모리에서 삭제한다.

 

즉, 클래스를 처음으로 참조할 때, 해당 클래스를 로드하고 링크한다는 것이다.

클래스 로더는 클래스 로딩(Class Loading)을 최대한 효율적으로 수행하기 위해 지연 로딩(Lazy-Loading)과 캐싱(Caching)같은 기법을 활용한다. 그러나 클래스 로딩이 런타임 메모리 관리처럼 대단히 까다로운 것이 아니기 때문에 이런 기법들은 비교적 간단한 편이다.

 

앞에서 알아보았던 JVM 스펙은 런타임에 클래스 로더에 질의(Query)하고 조작하기 위한 일반적인 방법들을 설명하고, 이런 기능은 JVM 구현에서 만들어진다.

개발자의 관점에서 볼 때, 근본적인 클래스 로더 매커니즘은 대개 블랙 박스다.

즉, 개발자들은 클래스 로더 메커니즘을 알지 않아도 된다.

 

JVM 실행 엔진 (Execution Engine)

클래스 로더가 JVM 내에 존재하는 런타임 데이터 영역에 클래스를 로딩하는 작업을 마치면, JVM은 각 클래스에 있는 코드를 실행하기 시작한다. 이 기능을 처리하는 것이 JVM 구성요소 중 하나이자, JVM 실행에 필수적인 실행 엔진이다.

 

.java 파일이 .class 파일로 컴파일 되며 인간이 알아보기 힘든 바이트 코드로 변환된다는 것은 지난 글에서 언급했었다.

하지만 기계가 읽고 바로 수행 가능한 정도가 아닌, 그나마 비교적 인간이 보기 편한 형태로 작성된다. 그래서 JVM 실행 엔진은 바이트 코드(.class 파일)를 JVM 내부의 기계가 읽고 실행할 수 있는 형태로 변경하는데, Interpreter(인터프리터)와 JIT(Just-In-Time) 컴파일러 등의 방식을 사용한다.

 

또한, 코드 실행에는 시스템 리소스에 대한 엑세스 관리가 관련되어 있다.

 

무슨 말이냐 하면, 프로그램을 실행하려면 파일이 필요하고 메모리 리소스가 요구될 것이며 네트워크도 필요할 경우가 있을 수 있다. JVM 실행 엔진은 그러한 프로그램 실행과 운영체제 가운데 위치해서 위와 같은 리소스들을 공급한다.

Interpreter (인터프리터)

먼저, 인터프리터 방식은 JVM 실행 엔진이 바이트 코드를 '명령어 단위'로 읽어서 실행한다.

하지만 이러한 방식은 한 줄 씩 수행하는 인터프리터 언어의 단점을 똑같이 갖고 있기 때문에 느리다.

JIT (Just-In-Time)

그래서 인터프리터 방식의 단점을 보완하기 위해 도입된 것이 JIT(Just-In-Time) 컴파일러이다.

 

인터프리터 방식으로 실행하다가 적절한 시점에 바이트 코드 전체를 컴파일하여 native 코드로 변경하고, 이후에는 더 이상 인터프리팅 하지 않고 네이티브 코드로 직접 실행하는 방식이다.

(여기서 native 코드란, CPU와 운영체제가 직접 실행할 수 있는 코드이다, 즉 기계가 바로 읽고 수행 가능한 코드)

 

네이티브 코드는 캐시에 보관하기 때문에 한 번 컴파일된 코드는 빠르게 수행되지만, JIT 컴파일러가 컴파일하는 과정은 바이트 코드를 인터프리팅 하는 것보다 훨씬 오래걸리므로 한 번만 실행되는 코드라면 컴파일하지 않고 인터프리팅 하는 것이 유리하다.

 

따라서 JIT 컴파일러를 사용하는 JVM들은 내부적으로 특정 메서드가 얼마나 자주 수행되는지 체크하고, 일정 정도를 넘을 때에만 컴파일을 수행한다.

Garbage Collection

시스템 리소스라 하면 크게 메모리와 메모리가 아닌 것, 2가지 범주로 나눌 수 있다.

메모리를 관리할 때는 메모리를 할당하거나 사용하지 않지만 할당되어 있는 메모리를 해제시켜야 한다.

가비지 컬렉션(Garbage Collection)이 그런 메모리의 해제나 폐기를 수행한다.

 

Runtime Data Area

Runtime Data Area는 프로그램을 수행하기 위해 아래 그림처럼 운영체제로부터 할당받은 메모리 공간이다.

두 그림 모두 같은 Runtime Data Area를 묘사한 그림이다.

출처) https://asfirstalways.tistory.com/158

 

출처) https://kingpodo.tistory.com/54

 

PC Register

컴퓨터 구조와 논리를 배웠다면 많이 본 PC 레지스터이다.

Thread가 시작될 때 생성되며, 스레드마다 하나씩 갖고 있다. 스레드가 어떤 부분을 어떤 명령어로 실행할 지에 대한 기록을 하며, 현재 수행 중인 JVM 명령어의 주소를 갖는다.

JVM stack 영역

프로그램 실행 과정에서 메서드를 빠져나가면 바로 소멸되는 특성의 데이터를 저장하기 위해 임시로 할당되는 영역이다.

 

메서드 안에서 사용되는 로컬 변수나, 호출된 메서드의 매개변수, 리턴 값 등 메서드의 정보 등을 임시로 저장한다.

메서드 호출 시마다 그 메서드만을 위한 stack frame이 생성되며, 메서드 수행이 끝나면 frame 별로 삭제한다.

Native method stack

위에서 잠깐 봤던 것처럼, 자바 프로그램이 컴파일되어 생성되는 바이트 코드보다 더 기계가 읽기 쉽도록 만들어지는 native 코드를 실행시키는 영역이다.

 

즉, 자바 언어를 위한 공간이 아니다.

 

native 코드를 Java Native Interface를 통해 바이트 코드로 전환하여 저장하게 되며, kernel이 stack을 할당하여 독자적으로 프로그램을 실행시킨다. 이 영역을 통해 C 코드를 실행시켜 kernel에 접근 가능하다.

Heap

new 연산자로 생성된 객체와 배열을 저장하는 가상 메모리 공간이며, GC의 관리 대상이다.

(아래 글 보다는 이후에 작성한 GC 글을 보는 것을 추천한다)

 

힙은 크게 세 부분으로 나눌 수 있다.

출처) https://asfirstalways.tistory.com/158

 

Permanent Generation은 생성된 객체들의 주소값이 저장된 공간이다.

Class loader에 의해 로드되는 class나 method 등에 대한 Meta 정보가 저장되며, JVM에 의해 사용된다.

Reflection이라는 방법을 사용하여 동적으로 클래스가 로딩되는 경우에 사용되는데, 내부적으로 reflection 기능을 자주 사용하는 Spring Framework을 이용할 경우, 이 영역에 대해 고려하며 코드를 작성해야 한다.

 

New/Young Generation에서 Eden은 객체들이 최초로 생성되는 공간이며, 여기에 객체가 가득차게 되면 첫 번째 GC(minor GC)가 발생한다.

Survivor 0 혹은 1은 Eden에서 참조되는 객체들이 저장되는 공간이며, Eden 영역에서 minor GC가 일어날 때, Eden 영역에 있는 값들을 Survivor 0 혹은 1 영역에 복사하고, 이 영역을 제외한 나머지 영역의 객체를 삭제한다.

 

Tenured Generation은 New Generation에서 일정 시간 참조되며 살아있는 객체들이 저장되는 공간이다.

Method Area (= Class Area = Static Area)

앞서 살펴본 Heap 영역이 객체를 위한 공간이라면, Method Area는 class 데이터를 위한 공간이다.

 

즉, class 정보를 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간이며, Heap과 마찬가지로 GC의 관리 대상에 포함된다.

 

올라가게 되는 메서드의 바이트 코드는 프로그램의 흐름을 구성하는 바이트 코드이다.

여기서 프로그램의 흐름이란, 자바 프로그램의 main 메서드의 호출에서부터 다른 메서드를 계속 호출하는 흐름이다.

 

이 공간에는 Runtime Constant Pool 이라는 별도의 관리 영역이 있는데, 상수 자료형을 저장하여 중복을 막는 역할을 수행한다.

올라가는 정보의 종류에는 세 가지가 있다.

 

(1) Field Information -> member 변수의 이름, 데이터 타입, 접근 제어자에 대한 정보

(2) Method Information -> method의 이름, 리턴 타입, 매개변수, 접근 제어자에 대한 정보

(3) Type Information -> class인지 interface인지의 여부 저장, Type의 속성, 전체 이름, super class의 전체 이름(interface이거나 object인 경우 제외)

 

---

 

뒷 부분으로 갈수록 꽤 어려운 내용들이 나온다.

 

추후 GC에 대해 좀 더 공부하고 글을 써봐야겠다.

 

끝!