자바의 컴파일 과정

  자바는 JVM(Java Virtual Machine) 덕분에 OS에 독립적인 특징을 가지고 있다. JVM의 어떠한 기능 때문에 OS에 독립적으로 실행시킬 수 있는지 자바의 컴파일 과정을 통해 알아보자.

 

 

📙 1. 컴파일 과정

  자바의 컴파일 과정은 다음과 같다.

1. 개발자가 작성한 자바 소스파일(*. java)을 자바 컴파일러(Java Compiler)가 바이트파일(*.class)로 컴파일한다. (CPU가 이해할 수 있는 언어인 바이너리 코드가 아니라 JVM이 이해할 수 있는 바이트 코드를 가진 바이트 파일로 변환한다.)
2. 클래스 로더(Class Loader)를 통해 바이트 파일(*.class)들을 JVM에 올린다.
3. JVM에 있는 바이트 파일(*.class)들은 실행 엔진(Execution Engine)의 인터프리터(Interpreter)와 JIT 컴파일러(JIT Compiler)를 통해서 해석된다.
4. 해석된 바이트 파일은 Runtime Data Areas에 배치되어 실질적인 수행이 이루어진다.

  컴파일 과정에서 나온 '실행 엔진 (Execution Engine), 런타임 데이터 영역 (Runtime Data Area), 가비지 컬렉터 (Garbage Collector)'에 대해서 자세히 알아보자.

 

 

📙 2. 실행 엔진 (Execution Engine)

  실행 엔진은 JVM 메모리에 올라온 바이트 코드들을 명령어 단위로 하나씩 가져와서 실행한다. 이때, 실행 엔진은 인터프리터(Interpreter)와 JIT 컴파일러(JIT Compiler)에 의해 동작된다.

 

  먼저, 인터프리터와 컴파일러에 대한 대략적인 차이를 먼저 알아보자.

  인터프리터는 컴파일러처럼 고레벨언어를 저레벨언어(기계어)로 해석해 주는 번역 프로그램이다. 컴파일러는 전체 소스코드를 보고 명령어를 수집하고 재구성하는 반면 인터프리터는 소스코드의 각 행을 연속적으로 분석하며 실행합니다. 

  그래서 일반적으로 각 행마다 실행하는 인터프리터보다는 컴파일러가 더 빠릅니다.

 

JVM에서의 인터프리터(Interpreter)와 JIT 컴파일러(JIT Compiler)에 대해서 알아보자.

📌 1. 인터프리터(Interpreter)

• 인터프리터는 바이트 코드 명령어를 하나씩 읽어서 해석하고 실행한다.
• 하나하나의 실행은 빠르나, 전체적인 실행 속도가 느리다는 단점이 있다.

📌 2. JIT 컴파일러(JIT Compiler)

• JIT 컴파일러는 인터프리터의 단점을 보완하기 위해 도입된 방식으로, 바이트 코드 전체를 컴파일하여 바이너리 코드로 변경한다.
• 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고, 바이너리 코드로 직접 실행하는 방식이다.
• 하나씩 인터프리팅하여 실행하는 것이 아니라 바이트 코드 전체가 컴파일된 바이너리 코드를 실행하는 것이기 때문에 전체적인(여기 볼드) 실행속도는 인터프리터를 이용하는 방식보다 빠르다.

 

  인터프리터를 이용하여 매번 코드를 한 줄씩 읽어 변환하게 되면 아무래도 미리 컴파일된 코드를 수행하는 것보다 느릴 수밖에 없다. 그렇다고, 바이트 코드 전체를 프로그램 수행 초기에 모두 컴파일하게 되면 초기 속도가 너무 느리게 된다.

  이러한 점들을 고려하여, 모든 코드는 초기에 인터프리터에 의해 시작되고, 해당 코드를 충분히 많이 사용할 경우 JIT 컴파일러에서 컴파일을 수행하게 된다.

 

 

📙 3. 런타임 데이터 영역 (Runtime Data Area)

  런타임 데이터 영역은 JVM의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 적재하는 영역을 말한다.

  런타임 데이터 영역은 크게는 5개, 작게는 6개의 영역으로 나눌 수 있다.

  메서드 영역(Method Area)과 힙 영역(Heap Area)은 모든 스레드가 공유해서 사용한다.

  스택 영역(Stack Area), PC 레지스터(PC Register), 네이티브 메서드 스택(Native Method Stack)은 스레드마다 하나씩 생성된다.

 

📌 메서드 영역(Method Area)

• 모든 스레드가 공유하는 영역으로 JVM이 시작될 때 생성된다.
• 클래스 멤버 변수의 이름, 데이터 타입, 접근 제어자 정보와 같은 각종 필드 정보들과 메서드 정보, 데이터 타입 정보, Constant Pool, static 변수, final class 등이 생성되는 영역이다.

📌 힙 영역(Heap Area)

• 인스턴스 또는 객체를 저장하는 공간으로 GC의 대상이 된다.
• JVM 성능 등의 이슈에서 가장 많이 언급되는 공간이다.

📌 스택 영역(Stack Area)

• 지역변수, 파라미터, 리턴 값, 연산에 사용되는 임시 값 등이 생성되는 영역이다.

📌 PC 레지스터(PC Register)

• 스레드가 생성될 때마다 생성되는 영역으로 프로그램 카운터, 즉 현재 스레드가 실행되는 부분의 주소와 명령을 저장하고 있는 영역이다.

📌 네이티브 메서드 스택(Native Method Stack)

• JAVA 외의 언어로 작성된 네이티브 코드를 위한 스택이다.
• JNI(JAVA Native Interface)를 통해 호출하는 C/C++ 등의 코드를 수행하기 위한 스택으로, 언어에 맞게 스택이 생성된다. (C의 경우 C스택, C++의 경우 C++스택이 생성된다.)

📌 런타임 상수 풀(Runtime Constant Pool)

• JVM 동작에서 가장 핵심적인 역할을 수행하는 곳으로 JVM 명세에서도 따로 중요하게 기술한다.
• 각 클래스와 인터페이스의 상수뿐만 아니라, 메서드와 필드에 대한 모든 레퍼런스까지 담고 있는 테이블로 어떤 메서드나 필드를 참조할 때 JVM은 런타임 상수풀을 통해 해당 메서드나 필드의 실제 메모리상 주소를 찾아서 참조한다.

 

 

📙 4. 가비지 컬렉터 (Garbage Collector)

  유효하지 않은 메모리(= 주소를 잃어버려서 사용할 수 없는 메모리)를 Garbage라고 하는데, Garbage Collector는 메모리가 부족할 때 이런 Garbage 메모리를 해제시켜 다른 용도로 사용할 수 있게 해주는 프로그램을 말한다.

  Garbage Collector를 수행할 땐 Garbage Collector를 수행하는 스레드를 제외한 모든 스레드들이 작업을 멈추게 된다. 그리고 GC의 작업이 완료되면 멈췄던 스레드들이 다시 작업을 시작한다.

  Garbage Collector에 대해서는 이후 글에서 자세히 다루는 것으로 하자.

 

해당 글은
키러니 님의 '알기쉽게 정리한 JAVA의 컴파일과정 및 JVM 메모리 구조, JVM GC',
KoB 님의 '[Java] 자바의 동작과정 Java Compiler와 JVM',
dalpang.e 님의 '[JAVA] JVM 동작원리 및 기본개념',
minseojo 님의 '[Java] 자바 컴파일 과정 & JVM 내부 구조',
Gyoogle 님의 '[Java] 컴파일 과정'
을 참고하였습니다.