JVM(Java Virtual Machine)

JVM(Java Virtual Machine)

JVM은 Java 책을 폈을 때 머릿말 혹은 가장 첫 단원에서 소개되지만 당장 프로그래밍 언어를 어떻게 사용할 것인지에 대해서만 관심이 있는 입문자들은 주의깊게 살펴보지 않는다. (실제로 우선 언어에 익숙해지고 난 뒤에 공부를 하는게 훨씬 이해하기도, 접근하기도 좋다고 생각한다.)

하지만 실무에서 개발을 함에 있어 성능 향상을 도모하고 메모리의 효율적인 관리를 위해서는 JVM에 대한 이해가 필수이므로 여기서 한 번 정리를 해보려 한다.

JVM이란

JVM이란 Java Virtual Machine의 약자로써 자바 어플리케이션 실행을 해 물리적 머신과 유사한 머신을 소프트웨어로 구현한 것이다.

JVM의 역할은 java application을 class loader를 통해 읽어들여 JAVA API와 함께 실행하는 것이다. 또한 JVM은 JAVA와 OS 사이의 중개자 역할을 수행함으로써 JAVA가 OS에 구애를 받지 않고 플랫폼 독립적으로 실행이 가능하게끔 하는 주체이며 메모리관리, Garbage Collection을 수행한다.

Java Application 실행 과정
  1. JVM이 OS로 부터 해당 Application에 필요한 메모리를 할당(Runtime Data Area)받는다. (JVM은 이 메모리를 여러 영역으로 나누어 관리한다.)
  2. 자바 컴파일러(javac)가 자바 소스코드(.java)를 읽어들여 바이트코드(.class)로 컴파일을 한다.
  3. Class loader를 통해 위의 class들을 JVM으로 로딩(Runtime Data Area에 배치)한다. 이 때에 Dynamic Loading(동적 로딩)을 함에 유의
  4. 로딩된 바이트 코드들은 **Execution engine(실행 엔진)**를 통해 해석된다.
  5. 해석된 바이트 코드들은 Runtime Data Area에 배치되어 실질적인 수행이 이루어진다.
  6. 이러한 실행 과정에서 JVM은 필요에 따라(혹은 설정에 따라) 쓰레드 동기화, Garbage Collection과 같은 관리 작업을 수행한다.
위 그림에서 보여지는 여러 키워드들 (Loading, Linking, JIT 등)에 대해서는 기회가 된다면 다른 포스팅에서 좀 더 자세히 설명을 할 예정이다. 우선은 JVM의 메모리 구조와 모듈들에 대해 좀더 집중을 해보자.

JVM 구성

Class loader(클래스 로더)

JVM 내로 클래스(.class)를 로드하고, 링크(참조되는 다른 클래스가 있을 경우 해당 클래스 까지 엮음)를 통해 배치를 수행하는 모듈이다.Runtime시에 동적으로 클래스를 로드하는데, 즉 어플리케이션 실행 중 어떤 클래스가 참조되어질 때에 Class loader가 해당 클래스를 JVM에 로드한다. 다시한번 강조하지만 자바는 컴파일 타임이 아닌 런타임 시에 클래스를 로드한다. 클래스를 처음으로 참조할 때 해당 클래스와 그 클래스가 참조하는 또 다른 클래스를 엮어서(링크) JVM의 메모리에 로드하고 이 역할을 클래스 로더가 수행한다.

Execution Engine(실행 엔진)

이름 그대로 클래스를 실행시키는 역할을 한다. 클래스 로더가 JVM 내의 Runtime Data Area 영역에 바이트 코드를 배치시키고, 이 바이트코드는 실행 엔진에 의해서 실행된다. 자바 바이트 코드는 기계(OS)가 바로 수행할 수 있는 형태가 아직 아니다. 이를 실행엔진이 실제 기계가 이해할 수 있는 형태로 변환한다. 이 때에 두 가지 방법이 사용된다.

  1. Interpreter(인터프리터) 실행엔진은 자바 바이트 코드를 명령어 단위로 읽어서 실행한다. 하지만 이 방법은 인터프리터의 단점을 고스란히 갖고있다. 하나의 단위로 해석하기 때문에 느리다는점.
  2. JIT(Just-In-Time) 인터프리터 방식의 단점을 보완하기 위해 도입된 JIT 컴파일러. 인터프리터 방식으로 실행을 하다가 어떤 적절한 시점에 바이트 코드 전체를 기계어로 번역하여 Native code로 변경하고 이후에는 더이상 인터프리팅이 아닌 변경된 Native code를 직접 실행하는 방식이다. 인터프리터 방식의 단점을 보완하기 위해 도입된 JIT 컴파일러. 인터프리터 방식으로 실행을 하다가 어떤 적절한 시점에 바이트 코드 전체를 기계어로 번역하여 Native code로 변경하고 이후에는 더이상 인터프리팅이 아닌 변경된 Native code를 직접 실행하는 방식이다. 인터프리터 방식의 단점을 보완하기 위해 도입된 JIT 컴파일러. 인터프리터 방식으로 실행을 하다가 어떤 적절한 시점에 바이트 코드 전체를 기계어로 번역하여 Native code로 변경하고 이후에는 더이상 인터프리팅이 아닌 변경된 Native code를 직접 실행하는 방식이다. 네이티브 코드는 캐시에 보관되기 때문에 한번 변환된 코드는 상당히 빠르게 수행된다. 물론 JIT 컴파일러가 네이티브 코드로 변환하는 과정은 바이트 코드를 인터프리팅 하는 속도보다 더 많은 시간이 소요되지만 우선 한 번 변환이 된 네이티브 코드를 실행하는 속도는 기존의 인터프리터 방식보다 훨씬 빠르기 때문에 여러번 실행되는 코드라면 인터프리팅 보다는 네이티브 코드로 변환하여 사용하는 것이 훨씬 효율적일 것이다. 따라서 JIT 컴파일러는 JVM 내부적으로 해당 메서드가 얼마나 자주 수행되는지 체크하여 일정 정도를 넘었을 때에 컴파일(네이티브 코드로 변환)을 수행한다.
Garbage Collector(가비지 컬렉터)

GC를 수행하는 모듈이 존재한다.

Runtime Data Area

프로그램을 실행하기 위해 OS로부터 할당받은 메모리 공간

PC Register

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

JVM Stack

프로그램 실행 과정에서 임시로 할당되었다가. 메소드를 빠져나가면 바로 소멸되는 특성의 데이터를 저장하기 위한 영역. 각종 형태의 변수나 임시 데이터, 스레드나 메소드의 정보를 저장한다. 메소드 호출시 마다 각각의 스택 프레임(그 메서드만을 위한 공간)이 생성된다. 메서드 수행이 끝나면 프레임 별로 삭제를 한다.메소드 안에서 사용되는 값들(Local Variable)을 저장한다. 또한 호출된 메서의 매개변수, 지역변수, 리턴 값 및 연산시 일어나는 값들을 임시로 저장한다.

######Native method Stack

자바 프로그램이 컴파일되어 생성되는 바이트코드가 아닌 실제 실행될 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다. JAVA가 아닌 다른 언어로 작성된 코드를 위한 공간.

######Method Area(= Class Area, = Static Area)

클래스 로더가 클래스 정보를 처음 메모리에 로드할 때 초기화 되는 대상을 저장하기 위한 메모리 공간. 올라가는 메소드의 바이트 코드는 프로그램의 흐을 구성하는 바이트 코드이다. 자바 프로그램은 main 메소드의 호출에서부터 계속된 호출로 이어나가기 때문. 대부분의 인스턴스도 메소드 내에서 명령하고 호출한다. 사실상 컴파일된 대부분의 바이트코드가 메소드 바이트 코드로 구성되어있기 때문에 거의 모든 바이트코드가 올라간다고 봐도 된다. 이 공간에는 Runtime Constant Pool이라는 별도의 관리 영역도 함께 존재한다. 이는 상수 자료형을 저장하여 참조하고 중복을 막는 역할을 수행한다. 올라가는 정보의 종류 1) Field Information 멤버변수의 이름, 데이터 타입, 접근 제어자에 대한 정보 2) Method Information 메소드의 이름, 리턴타입, 매개변수, 접근제어자에 대한 정보 3) Type Information class인지 Interface인지의 여부 저장 이 외에도 Static 변수, final class 변수 등

Method Area가 클래스 데이터를 위한 공간이라면 Heap 영역은 객체를 위한 공간이다. Heap과 마찬가지로 GC의 관리 대상이다.

Heap Area

객체를 저장하는 가상 메모리 공간이다. new 연산자로 생성된 객체와 배열을 저장한다. 물론 Method Area영역에 로드된 클래스들만 객체로 생성이 가능하다. 힙은 아래와 같이 크게 3영역으로 나눌 수 있다.

Permanent Generation 생성된 객체 정보들의 주소값이 저장된 영역이다. 클래스 로더에 의해 로드되는 Class, Method 등에 대한 Meta 정보가 저장되는 영역이고 JVM에 의해 사용된다. Reflection을 사용하여 동적으로 클래스가 로딩되는 경우에 사용된다. 내부적으로 Reflection 기능을 자주 사용하는 Spring Framework를 이용할 경우 이 영역에 대한 고려가 필요하다.

NEW / YOUNG

  • Eden : 객체들이 최초로 생성되는 공간.
  • Survivor 0 / 1 : Eden에서 참조되는 객체들이 저장되는 공간.

Old New Area에서 일정 시간 참조되고 있는, 살아남은 객체들이 저장되는 공간. Eden 영역에 객체가 가득 차게되면 첫 번째 GC(Minor GC)가 발생한다. Eden 영역에 있는 값들을 Survivor 1 영역에 복사하고 이 영역을 제외한 나머지 영역의 객체를 삭제한다.

인스턴스는 소멸 방법과 소멸 시점이 지역변수와는 다르기에 힙이라는 별도의 영역에 할당된다. JVM은 매우 합리적으로 인스턴스를 소멸시킨다.