3.1 JVM(Java Virtual Machine, 자바 가상 머신)이란?

<aside> 💡 위키(Wikipedia)에서는 JVM을 자바 다는 뜻이다. 컴파일된 바이너리 코드는 어떤 JVM에서도 실행할 수 있게 된다.

</aside>

1. JVM은 자바와 운영체제 사이의 중계자 역할을 하여, 자바가 운영체제에 의존하지 않고 실행될 수 있게 한다.
2. 대표적인 컴퓨터 아키텍처인 인텔 x86 아키텍처나 ARM 아키텍처와 같은 하드웨어가 레지스터 기반으로 동작하는데 비해 JVM은 스택 기반으로 동작한다.

자바 프로그램은 완전한 기계어가 아닌, 중간 단계의 [바이트코드(Bytecode)](<https://henu.notion.site/2-594202d059cd48ce9cf1e476d5e6d9b0>)이기 때문에 이것을 해석하고 실행할 수 있는 가상의 운영체제가 필요하다. 이것이 자바 가상 머신(JVM: Java Virtual Machihe)이다.

1. 심볼릭 레퍼런스(Symbolic Reference)
   • [ ] 기본 자료형(Primitive Data Type)을 제외한 모든 타입(클래스와 인터페이스)을 명시적인 메모리 주소 기반의 레퍼런스가 아니라 심볼릭 레퍼런스를 통해 참조한다.
2. JVM은 메모리 관리, [가비지 컬렉션(GC: Garbage Collection)](<https://henu.notion.site/8-0a9c3048fa2c428e9ab7902e13b015b2>)을 수행한다.
   • [ ] 클래스 인스턴스는 사용자 코드에 의해 명시적으로 생성되고 가비지 컬렉션에 의해 자동으로 파괴된다.
3. C와 C++ 등의 전통적인 언어는 플랫폼에 따라 int 형의 크기가 변한다. 하지만 JVM은 기본 자료형을 명확하게 정의하여 호환성을 유지하고 플랫폼 독립성을 보장한다.
4. 네트워크 바이트 오더(Network Byte Order)
   • [ ] 자바 클래스 파일은 네트워크 바이트 오더를 사용한다. 인텔 x86 아키텍처가 사용하는 리틀 엔디안이나, RISC 계열 아키텍처가 주로 사용하는 빅 엔디안 사이에서 플랫폼 독립성을 유지하려면 고정된 바이트 오더를 유지해야 하므로 네트워크 전송 시에 사용하는 바이트 오더인 네트워크 바이트 오더를 사용한다. 네트워크 바이트 오더는 빅 엔디안이다.

<aside> 💡 자바를 이용하여 개발하는 개발자라면 누구나 자바 바이트코드가 JRE(Java Runtime Environment, 자바 실행 환경) 위에서 동작한다는 사실을 잘 알고 있다. 이 JRE에서 가장 중요한 요소는 자바 바이트코드를 해석하고 실행하는 JVM이다. JRE는 자바 API와 JVM으로 구성되며, JVM의 역할은 자바 애플리케이션을 클래스 로더(Class Loader)를 통해 읽어 들여서 자바 API와 함께 실행하는 것이다.

</aside>

3.2 JVM 구조

JVM은 크게 클래스 로더(Class Loader), 런타임 데이터 영역(Runtime Data Areas), 실행 엔진(Execution Engine)으로 구성되어 있다. 자바 소스 파일로 작성한 코드는 클래스 로더가 컴파일된 자바 바이트코드를 런 타임 데이터 영역에 로드하고, 실행 엔진이 자바 바이트코드를 실행한다.

[부록 그림 3 - 1] 자바 소스 파일 실행 과정

구성요소

1. 클래스 로더(Class Loader)

   • [ ] JVM 내 클래스(*.class) 파일을 로드하고, 링크를 통해 배치하는 작업을 수행한다.
   • [ ] Runtime 시에 동적으로 클래스를 로드한다.
     • 자바는 동적 로드, 즉 Compile time이 아니라 Runtime에 클래스를 처음으로 참조할 때 해당 클래스를 로드하고 링크하는 특징이 있다.
   • [ ] *.jar 파일 내 저장된 클래스들을 JVM 위에 탑재하고 사용하지 않는 클래스들을 메모리에서 삭제한다.

2. 실행 엔진(Execution Engine)

   • [ ] 클래스를 실행시키는 역할을 한다.

     • 클래스 로더를 통해 JVM 내의 런타임 데이터 영역에 배치된 자바 바이트코드는 실행 엔진에 의해 실행된다.
     • 자바 바이트코드를 명령어 단위로 읽어서 실행한다.

     <aside> 💡 이와 같은 바이트코드는 JVM 내부에서 기계가 실행할 수 있는 형태로 변환되며, 이는 [인터프리터(Interpreter)](<https://henu.notion.site/5-f94d38bfec314b9dac488deeb015f0f4>), [JIT(Just-In-Time)](<https://henu.notion.site/7-JIT-3a3f2f153b924ce6abc49396b0f12f32>) 방식으로 진행된다.

     </aside>

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

   • [ ] JVM이 프로그램을 수행하기 위해 운영체제(OS) 위에서 실행되면서 할당받는 메모리 영역이다. 런타임 데이터 영역은 크게 6개의 영역으로 나눌 수 있다. 이중 PC 레지스터(PC Register), JVM 스택(JVM Stack), 네이티브 메소드 스택(Native Method Stack)은 쓰레드(Thread)마다 하나씩 생성되며 힙(Heap), 메소드 영역(Method Area), 런타임 상수 풀(Runtime Constant Pool)은 모든 쓰레드가 공유해서 사용한다.

   • [ ] 각 영역의 특징

     

     [부록 그림 3 - 2] 런타임 데이터 영역의 구조

     • PC 레지스터
       1. 각 쓰레드마다 하나씩 존재하며 쓰레드가 시작될 때 생성된다.
       2. 쓰레드가 어떤 부분을 어떤 명령으로 실행해야 할 지에 대한 기록을 하는 부분이다.
       3. 현재 수행 중인 JVM 명령의 주소를 갖는다.
     • JVM 스택

       1. 쓰레드가 시작될 때 생성되며, 각 쓰레드 별로 생성이 되기 때문에 다른 쓰레드는 접근할 수 없다.

       2. 스택 프레임(Stack Frame)이라는 구조체를 저장하는 스택으로 JVM은 오직 JVM 스택에 스택 프레임을 추가(Push)하고 제거(Pop)하는 동작만 수행한다.

          

          [부록 그림 3 - 3] JVM 스택 구성

          <aside> 💡 스택 프레임(Stack Frame)은 JVM 내에서 메소드(Method)가 수행될 때마다 하나의 스택 프레임이 생성되어 해당 스레드의 JVM 스택에 추가되고 메서드가 종료되면 스택 프레임이 제거된다. 각 스택 프레임은 지역 변수 배열(Local Variable Array), 피연산자 스택(Operand Stack), 현재 실행 중인 메서드가 속한 클래스의 런타임 상수 풀에 대한 레퍼런스를 갖는다. 지역 변수 배열, 피연산자 스택의 크기는 컴파일 시에 결정되기 때문에 스택 프레임의 크기도 메서드에 따라 크기가 고정된다.

          </aside>

       3. 예외 발생 시 printStackTrace() 등의 메소드로 보여주는 Stack Trace의 각 라인은 하나의 스택 프레임을 표현한다.

     • 네이티브 메소드 스택
       1. 자바 외의 언어로 작성된 네이티브 코드를 위한 스택이다. 즉, JNI(Java Native Interface)를 통해 호출하는 C / C++ 등의 코드를 수행하기 위한 스택으로, 언어에 맞게 C 스택이나 C++ 스택이 생성된다.
       2. 네이티브 메소드를 위해 네이티브 메소드 스택이라는 메모리 공간을 갖는다. 애플리케이션에서 네이티브 메소드를 호출하게 되면 네이티브 메소드 스택에 새로운 스택 프레임을 생성하여 추가(Push)한다. 이는 JNI를 이용하여 JVM 내부에 영향을 주지 않기 위함이다.
     • 메소드 영역

       1. 모든 스레드가 공유하는 영역으로 JVM이 시작될 때 생성된다.

       2. JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메소드 정보, Static 변수, 메소드의 바이트코드 등을 보관한다.

          <aside> 💡 메소드 영역에 올라가는 정보의 종류

          • Field Information : 멤버 변수의 이름, 데이터 타입, 접근 제어자에 대한 정보
          • Method Information : 메소드의 이름, 리턴 타입, 매개변수, 접근 제어자에 대한 정보
          • Type Information : 클래스인지 인터페이스인지의 여부 저장, Type의 속성, 전체 이름, Super 클래스의 전체 이름 등

          </aside>

       3. 메소드 영역은 JVM 벤더마다 다양한 형태로 구현할 수 있으며, 오라클 핫스팟 JVM(HotSpot JVM)에서는 흔히 Permanent Area, 혹은 Permanent Generation(PermGen)이라고 불린다. 메서드 영역에 대한 가비지 컬렉션은 JVM 벤더의 선택 사항이다.

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

       1. 프로그램 상에서 런타임 시 동적으로 할당하여 사용하는 영역이다.

       2. new 키워드를 사용하여 생성된 객체와 배열, 인스턴스 등을 저장하는 가상 메모리 공간이다.

       3. 가비지 컬렉션(Garbage Collection)의 대상이 된다.

       4. JVM 성능 등의 이슈에서 가장 많이 언급되는 공간이다.

          <aside> 💡 힙 구성 방식이나 가비지 컬렉션 방법 등은 JVM 벤더의 재량이다.

          </aside>

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

          

          [부록 그림 3 - 4] 힙 구성

          • Permanent Generation : 클래스, 메소드의 메타(Meta) 정보, Static 변수와 상수 정보들이 저장되는 공간이다. 이 영역은 Java 8 부터는 Native 영역으로 이동하여 Metaspace 영역으로 변경되었다.
          • New / Young 영역 : 객체를 생성하자마자 저장되는 공간이 Eden 영역이다. 만약 Eden 영역이 꽉 차면 살아있는 객체만 Survivor 영역으로 복사되고, 다시 Eden 영역을 채우게 된다. Survivor 영역이 꽉 차게 되면 다른 Survivor 영역으로 객체가 복사되는데 이때, Eden 영역에 있는 객체들 중 살아있는 객체들도 다른 Survivor 영역으로 간다. 즉, Survivor 영역의 둘 중 하나는 반드시 비어 있어야만 한다.
          • Old 영역 : New / Young 영역에서 일정 시간 참조되고, 오래 살아있는 객체들이 저장되는 공간이다.