[ JAVA ] JVM

JVM은 무엇일까?

Java Virtual Machine 의 약자로, 자바를 실행하기 위한 가상 기계라고 할 수 있다. 여기서 가상 기계란 소프트웨어로 구현된 하드웨어를 뜻하는 넓은 의미의 용어이다. ( 컴퓨터 성능의 향상으로 많은 소프트웨어들이 소프트웨어화되어 컴퓨터 속으로 들어오고 있다 )

 

쉽게 말해

자바를 실행하기 위한 가상의 컴퓨터

라고 이해하면 좋을 것이다.

 

자바로 작성된 애플리케이션은 모두 이 가상 컴퓨터(JVM) 에서만 실행되기 때문에 자바 어플리케이션이 실행되기 위해서는 반드시 JVM이 필요하다.

 

JVM 은 왜 필요할까?

앞서 자바 어플리케이션이 실행되기 위해서는 반드시 JVM 이 필요하다고 했는데 이게 왜 반드시 필요한 것일까?

 

컴퓨터는 기계어만 알아들을 수 있기 때문에 사람이 작성한 코드를 컴퓨터가 알아들을 수 있게 컴파일러를 통해 번역해주어야 한다. 이렇게 컴파일러가 사람이 작성한 코드를 0과 1로 이루어진 기계어로 컴파일 해주었을 때 비로소 컴퓨터가 거기에 맞게 행동할 수 있는 것이다. 

 

하지만 기계어는 실행환경에 따라 쓰이는 기계어가 다르기 때문에 실행환경에 맞게끔 컴파일 해주어야한다. 이를 해결하기 위해 필요한 것이 바로 JVM이다. 

 

 

Java 로 프로그래밍을 하고 컴파일을 거치면 바로 기계어로 변환되지 않고 바이트 코드(.class)로 변환된다. 그리고 만약 전달해주는 컴퓨터에 JVM이 존재한다면 JVM은 이를 받아서 실행환경에 맞게끔 기계어로 번역해주고 컴퓨터는 기계어로 프로그래밍 명령을 실행할 수 있는 것이다.

 

요약하자면 JVM은 자바 코드와 기계어 사이에 존재하는 바이트 코드를 JVM이 깔린 어떤 종류의 실행환경에서도 돌아갈 수 있게끔 도와주기 위해 존재하는 것이다. 그리고 이러한 JVM으로 인해 자바의 중요한 장점 중 하나인 "한번 작성하면 어디서든 실행된다" (Write once, run anywhere) 가 가능하게 되는 것이다.

 

일반 애플리케이션과 자바 애플리케이션 비교

일반 어플리케이션의 경우, 코드가 OS만 거치고 하드웨어로 전달되며 OS에 바로 맞붙어 있기 때문에 OS에 종속적이다. 즉, 애플리케이션을 다른 OS에서 실행시키기 위해서는 그 OS에 맞게끔 변경해야 한다.

 

반면 Java 어플리케이션은, JVM 하고만 상호작용하기 때문에 OS에 독립적이다. 즉, 애플리케이션을 다른 OS에 실행시키기 위해서 변경할 필요가 없다. 물론 애플리케이션이 독립적인 것이고 애플리케이션 대신 OS와 맞붙어있는 JVM은 OS에 종속적이다. 즉, 해당 OS에 실행가능한 JVM이 필요하다.

자바 애플리케이션이 JVM을 한번 더 거치고, 하드웨어에 맞게 완전히 컴파일된 상태가 아니고 실행 시에 해석되기 때문에 속도가 느리다는 단점을 가지고 있지만 요즘들어 바이트코드(컴파일된 자바 코드)를 기계어로 바로 변환해주는 JIT 컴파일러와 향상된 최적화 기술이 적용되어 속도 차이를 많이 줄였다. 

 

요약하자면 다음과 같다. 

 

일반 어플리케이션

• OS에 종속적이다.
• 상대적으로 빠르다.

자바 어플리케이션

• OS에 독립적이다. ( JVM이 종속적이다. )
• 상대적으로 느리다. ( 최근 격차가 많이 줄었다. )

 

JVM 의 수행 과정 ( 동작 방식 )

지금까지 글을 읽었다면 JAVA 어플리케이션이 수행되기 까지 .java(소스 코드) -> 컴파일러 -> .class(바이트 코드) -> jvm -> 실행의 순서를 가진다는 것을 알 수 있을 것이다. 그렇다면 JVM 내부에서 바이트 코드를 어떻게 처리하는지 알아보자.

JVM은 컴파일된 바이트 코드를 받은 다음 아래와 같은 순서로 처리한다.

1. Class Loader 모듈을 사용해서 런타임 시에 동적으로 클래스를 RunTime Data Area에 로드한다.
2. RunTime Data Area에 로딩된 class 들은 Execution Engine을 통해 해석된다.
3. 해석된 바이트 코드는 Runtime Data Area의 각 영역에 배치되어 수행되며 이 과정에서 Execution Engine에 의해 GC의 작동과 Thead 동기화가 이루어진다.

각 모듈에 대해서도 알아보자

 

Class Loader

• JVM 내로 클래스 파일을 로드하고, 배치하는 작업을 수행하는 모듈

Execution Engine

• 클래스 로더를 통해 JVM 내의 Runtime Data Area에 배치된 바이트 코드들을 명렁어 단위로 읽어서 실행.

최초 JVM이 나왔을 당시에는 인터프리터 방식이었기때문에 속도가 느리다는 단점이 있었지만 JIT 컴파일러 방식을 통해 이 점을 보완한다. JIT는 바이트 코드를 어셈블러 같은 네이티브 코드로 바꿈으로써 실행이 빠르지만 역시 변환하는데 비용이 발생했는데 이를 해결하기 위해 JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않고, 인터프리터 방식을 사용하다가 일정한 기준이 넘어가면 JIT 컴파일러 방식으로 실행한다.

 

Garbage Collector

Garbage Collector(GC)는 힙 메모리 영역에 생성된 객체들 중에서 참조되지 않은 객체들을 탐색 후 제거하는 역할을 한다. 이때, GC가 역할을 하는 시간은 언제인지 정확히 알 수 없다.

 

Runtime Data Area

JVM의 메모리 영역으로 자바 애플리케이션을 실행할 때 사용되는 데이터들을 적재하는 영역이다. 이 영역은 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.

 

이제 동작 과정을 과정에 따라 좀 더 상세화한 도식으로 알아보자

 

JVM의 메모리 구조

응용 프로그램이 실행되면, JVM은 시스템으로부터 프로그램을 수행하는데 필요한 메모리를 할당 받고 JVM은 이 메모리를 용도에 따라 여러 영역으로 나누어 관리한다는 것을 알 수 있다. 이제 이 메모리 영역의 구조를 알아보자.

 

메서드 영역 ★

모든 쓰레드가 공유하는 메모리 영역이며 클래스에 대한 정보(클래스 데이터)를 저장하는 영역이다. 클래스, 인터페이스, 메서드, 필드, static 변수 등의 바이트 코드를 보관한다.

힙 영역 ★

모든 쓰레드가 공유하며 인스턴스 변수, new 키워드로 생성된 객체와 배열이 생성되는 동적인 영역이다. 또한 메서드 영역에 로드된 클래스만 생성이 가능하고 GC가 참조되지 않는 메모리를 확인하고 제거하는 영역이다. 즉 프로그램 실행 중 생성되는 인스턴스들이 생성되는 공간이다.

호출 스택 영역 ★

 메서드 작업에 필요한 메모리 공간을 제공한다. 메서드가 작업을 수행하는 동안 지역변수들과 연산의 중간결과 등을 저장하는데 사용되며 작업을 마칠 경우 할당되었던 메모리 공간은 반환되어 비어진다. 즉, 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시에 일어나는 값들을 임시로 저장하는 공간이다.

 

이 영역은 다음과 같이 메서드가 호출될 때마다 수행에 필요한 메모리를 스택에 할당받고 수행을 마치고 나면 사용했던 메모리를 반환하고 스택에서 제거가 된다. 만약 첫 번째 메서드를 실행하던 중에 다른 메서드를 호출하면 메서드 위에 두 번째 호출된 메서드를 위한 공간이 마련된다. 반환타입이 있는 메서드의 경우 종료되며 결과값을 자신을 호출한 메서드에게 반환하고 대기상태에 있는 메서드는 넘겨받은 반환값으로 수행을 계속 진행하게 된다.

PC Register

쓰레드가 시작될 때 생성되며 생성되는 공간으로 쓰레드마다 하나씩 존재한다. 쓰레드가 어떤 부분을 무슨 명령으로 실행할지에 대한 기록을 하는 부분으로 현재 수행중인 JVM 명령의 주소를 갖는다.

Native Method Stack

자바 외 언어로 작성된 네이티브 코드를 위한 메모리 영역이다.