JVM이야기 - 정의(+JRE, JDK), 구조

 

 

JVM (Java Virtual Machine ) 자바 가상 머신

---

컴퓨터는 0과 1로 이루어진 바이너리(2진수)로 작성된 기계어로만 이해를 할 수 있다. 하지만 사람은 그 기계어를 보고 이해하기가 어렵다. (모니터에 0110101010110 이렇게만 써있으면, 난감하다^^;)

 

어쨋든 우리가 이해하고 작성할 수 있는 프로그래밍 언어를 컴퓨터가 알아들을 수 있는 기계어로 바꿔주는 작업을 다행히도 c나 자바 같은 컴파일 언어에서는 컴파일러라는 번역가가 번역을 해준다. 그런데 c같은 경우는, 똑같이 c로 짠 프로그래밍이더라도 윈도우에서 돌게 컴파일한 것은 맥이나 리눅스에서 안돈다. 즉, 프로그램이 도는 환경, 컴퓨터마다 거기에 맞는 기계어로 일일이 번역을 해줘야한다.

 

이런 문제를 해결하기 위해 만들어진 게 자바의 JVM이다. 쉽게 말해서 각 종류의 컴퓨터마다 JVM이라는 전담 통역센터가 있다고 생각하면 된다. 밑에서 다시 자세히 설명하겠지만, 우리가 작성하는 자바 소스코드는 0과 1로 이루어진 기계어로 번역되기 전에 바이트코드로 이루어진 클래스파일로 컴파일 되는데, 이 바이트코드를 각 컴퓨터에 깔려있는 JVM에게 갖다주면, 그 컴퓨터가 이 프로그램을 실행할 때 이 JVM이 바이트 코드를 그때그때 기계어로 통역을 해준다. 그래서 Write Once Run Anywhere 이라는 말이 나왔는데, 한번 작성하면 어디서든 작동되도록 해준다는 뜻이 바로 이런 의미이다. 

 

 

JRE (Java Runtime Environment) 자바 실행 환경

---

런타임이라는 말은 컴파일타임과 대조되는 말이다. 컴파일은 코딩 이후에 이것을 실행하거나 배포하기 전에 '미리' 해두는 번역작업을 말하는데, 결국 컴파일 타임은 이 작업을 하는 시점을 말한다. 런타임은 반대로 이것을 run, 실행하는 시점을 말한다. 그렇다면 자바 런타임 환경이라는 말이 이해가 될 것이다. 자바로 짠 소프트웨어가 컴파일 및 빌드까지 다 된 다음 이를 사용할 곳에 주어져서 실행이 될 때 그 환경 요소들로서 필요한 것들을 말한다. (시스템은 코드 말고도 여러가지가 필요하다. 예를 들어 자바의 List, Map 등 이런 자료구조를 쓸 수 있는게, 우리가 직접 이 기능들을 구현해서가 아니라 이것들이 바이트코드로 컴파일된 클래스로 제공이 되기 때문에 쓸 수 있는 것이다.) JVM에서 도는 라이브러리들을 JVM이랑 세트로 묶어다가 다운받아 설치할 수 있도록 한 것이 JRE 이다. 이 JRE만 깔면 어떤 컴퓨터든 자바로 작성한 프로그램을 돌릴 수 있게 된다. 

 

그런데 요즘엔 JRE가 잘 안보인다. 이유는? 바로 JDK에 있다.

 

 

JDK(Java Development Kit) 자바개발도구

---

JDK는 JRE를 포함하고 있다. JRE 에다가 자바 코드를 컴파일할때 쓰는 javac, 자바를 디버깅할 때 쓰는 jdb, 서로 연관 있는 클래스들을 하나의 jar 파일로 묶어주는 jar 등등의 사용자가 아닌 프로그래머를 위한 기능들도 같이 탑재를 하고 있다. 

 

예전에는 사용자들이 자바 프로그램을 돌리려면 JRE를 따로 설치해야했지만, 요즘엔 개발자가 배포하는 자바 프로그램에 JRE랑 JVM 요소들까지 다 같이 끼워넣어서 프로그램만 받아서 실행시키면 되도록 한다. 그리고 자바 돌리는 서버같은 경우에는 그냥 아에 JDK를 설치해서 사용한다. 

 

 

JVM 구조

---

JVM 구조

 

자바 소스 코드는 .java 파일로 저장되게 된다. 이 소스 파일은 자바 컴파일러가 byte code로 이루어진 .class 파일로 컴파일해준다. 

이렇게 byte code로 바꿔버리면, 이는 작성한 코드를 1차적으로 숨기는 역할을 할 뿐만 아니라, 이제 byte code로 바꿔버렸으니 문법 검사등을 하지 않는 시간을 단축시키는 역할을 한다. 하지만 결국은 소스 코드 변경시마다 컴파일을 하고 실행시키기때문에, 시간이 오래 걸린다.

 

이렇게 변경된 파일은 Class Loader에 의해 JVM 메모리 영역, 즉 Runtime Data Area로 로딩시킨다. Runtime Data Area는 아래 그림과 같이 5가지 영역으로 나눠져있다.

 

모든 스레드가 공유하는 영역인 Method Area, Heap이 있고, 스레드마다 하나씩 생성되는 Stack, PC Register, Native Method Stack 영역이 있다. 

 

MethodArea 영역은 JVM이 시작될 때 생성되는 공간으로 바이트코드가 이 영역에 저장된다. 뿐만 아니라 모든 스레드가 공유하는 영역이라고 했는데, 여기에는 클래스 정보, 변수 정보, static으로 선언한 공유변수가 저장된다.

 

Heap 영역은 new 연산을 통해 동적으로 생성된 객체가 저장되는 영역으로 GC의 대상이 되는 공간이다. 해당 객체가 소멸되기 전이나 GC의 대상이 되어 정리되기 전까지는 남아있다. (Heap영역의 구조와 GC에 대한 글은 아래 링크를 참조) 

 

https://mong-dev.tistory.com/16

Garbage Collector 이야기 - 정의, 왜, 언제, 어떻게, 알고리즘, 종류

 

Stack 영역은 지역변수, 메서드의 매개변수, 임시적으로 사용되는 변수, 메서드의 정보가 저장되는 영역이다. 지역변수와 매개변수의 특성상 해당 메서드의 호출이 종료되면, 이 안에 선언된 변수들은 사라진다. 주로 금방 사용되고 사용이 끝나는 데이터가 저장되는 영역이다.

참고로, 우리가 Person p = new Person("daramii", 30); 을 입력했다고 가정해보자. 이렇게 동적으로 생성한 Person 객체를 참조하는 변수 p는 stack영역에 저장이 되고, new 연산자를 통해 동적으로 선언한 Person객체 자체는 Heap영역에 저장되는 것이다.

 

PC Register는 스레드가 시작될 때 생성되며, 현재 수행중인 JVM의 명령어 주소를 저장하는 공간이다. 즉, 스레드가 어떤 부분을 어떤 명령어로 수행할지 저장하는 공간이다.

 

Native Method Stack은 JAVA가 아닌 다른 언어로 작성된 코드를 위한 공간이다. 즉, JNI(Java Native Interface)를 통해 호출하는 C/C++ 등의 코드를 수행하기 위한 공간이다. 자바 프로그램이 컴파일되어 생성되는 바이트 코드가 아닌 실제 실행할 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다.

 

이제 Runtime Data Area에 로딩된 클래스파일이 Execution Engine을 통해 해석이 된다.

 

Execution Engine은 말그대로 바이트코드를 실행하는 엔진이다. 우선 바이트코드를 컴퓨터가 이해할수있는 기계어로 변경해주는 작업이 필요할 것이다. 그림에서 보이는 interpreter는 명령어를 한줄 한줄 해석하며 실행한다. JIT(Just In Time) Compiler는 interpreter의 단점을 보완하는 방법으로, runtime 시점에 한꺼번에 해석하여 실행한다. 

 

이제 이렇게 기계어로 해석된 것들이 Runtime Data Area에 배치되어 스레드 동기화나 GC을 수행하게 된다.

 

마지막으로, Native Method Interface(JNI)는 JVM에 의해 실행되는 코드 중 네이티브로 실행하는 것이 있다면, 해당 네이티브 코드를 호출하거나 호출 될 수 있도록 만든 일종의 프레임워크이다.

Native Method Library는 Native Method 실행에 필요한 라이브러리이다.