JVM 메모리 구조에 관하여

HyunKyu Lee·2023년 12월 7일

JVM Java

자바를 계속 사용하면서 JVM에 대한 이해가 부족한 것 같아 JVM에 관해 공부해보기로 했다. 우선 JVM이 무엇인지부터 시작해보자

JVM이란?

Java Virtual Machine의 줄임말.
Java는 OS종속적이지 않다는 특징을 갖고 있다. OS종속받지 않고 실행시키려면 OS위에서 JAVA를 실행시킬 무언가가 필요한데 그게 바로 JVM이다.

Java 프로그램 실행 단계

다음 그림을 살펴보면 각 OS위에서 JVM이 동작하고 이 JVM이 Java compiler가 컴파일한 바이트 코드를 해석하는 걸 볼 수 있다.
여기서 JVM이 하는 역할은 byte code를 각 OS에서 해석될 수 있도록 변환하고 실행시키는 것이다.
이에 따라 각 OS에 맞는 JVM만 설치한다면 JAVA코드를 실행시킬 수 있다.
여기서 JVM은 각 OS에 종속적이라는 것을 알 수 있다.

JVM 동작 방식

Java를 실행하면 JVM은 OS로부터 메모리를 할당받는다.
javac (컴파일러)가 java 소스코드를 바이트코드로 컴파일한다.
Class Loader는 동적 로딩을 통해 필요한 클래스들을 로딩 및 링크하여 Runtime Data Area에 올린다.
-> 여기서 Runtime Data Area는 Java가 메모리를 실질적으로 관리하는 영역이다.
Runtime Data Area에 로딩 된 바이트 코드는 Execution Engine을 통해 해석된다.
이 과정에서 Execution Engine에 의해 Garbage Collection의 작동과 Thread 동기화가 이루어진다.

Garbage Collection과 Thread 동기화
enterprise java환경에서 성능에 가장 많은 영향을 미치는 것은 Garbage Collection(GC) 이다. GC가 발생하는 동안 java thread는 어떤 식으로든 작동을 멈추거나 지연이 발생하게 된다. 이런 멈춤 현상이나 지연이 자주 발생하게 된다면 성능에 치명적인 영향을 미친다.
여기서 GC에 의한 성능 저하가 thread 동기화와 어떤 연관성이 있는지 갸우뚱 할 수도 있다. 하지만 내부 동작을 들여다보면 GC가 진행될 때 메모리 자원들 둘러싼 Thread의 동기화 문제로 인해 성능이 저하되는 것을 확인할 수 있다. Thread가 특정 메모리 영역을 사용하려고 하는 시점에 해당 메모리 영역에 GC 작업이 발생하게 된다면 Thread가 Blocking되면서 성능 저하 현상이 발생하는 것이 우리가 겪는 GC의 성능 문제이다.

JVM 구조

위에서 다뤄본 JVM동작 과정 중 Class Loader - Execution Engine - Runtime Data Area 부분을 상세화 하였다.

JVM 구성

클래스 로더(Class Loader)
실행 엔진(Execution Engine)
- 인터프리터(Interpreter)
- JIT 컴파일러(Just-in-Time)
- 가비지 콜렉터(Garbage collector)
런타임 데이터 영역 (Runtime Data Area)
- 메소드 영역
- 힙 영역
- PC Register
- 스택 영역
- 네이티브 메소드
JNI - 네이티브 메소드 인터페이스 (Native Medthod Interface)
네이티브 메소드 라이브러리 (Native Method Library)

클래스 로더 (Class Loader)

클래스 로더는 JVM 안에서 컴파일된 class 파일을 동적으로 로드하고 링킹하는 모듈이다.
즉 로드된 class파일들을 링킹하여 JVM memory인 Runtime Data Areas에 배치한다.

class파일의 로딩 순서는 다음과 같이 구성된다.

1. Loading : class파일을 가져와서 JVM memory에 로드한다.
2. Linking : class파일을 사용하기 위해 검증하는 과정.

Verifying(검증) : class가 JVM 명세에 명시된 대로 구성되어 있는지 검사한다.
Preparing(준비) : 클래스가 필요로 하는 메모리를 할당한다.
Resolving(분석) : 클래스의 상수 플 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경한다. (메모리 영역에 클래스의 static 값들을 할당한다.)

3.Initialization : 클래스 변수들을 적절한 값으로 초기화한다.

Resolving 단계

심볼릭 메모리 레퍼런스를 메소드 영역에 있는 실제 레퍼런스로 교체한다.

public class GidhubApplication {
    HelloGid helloGid = new HelloGid();

    public static void main(String[] args) {
        SpringApplication.run(GidhubApplication.class, args);
    }
}

HelloGid helloGid = new HelloGid()에서 new HelloGid() 부분은 실제 레퍼런스를 가리키진 않는다.
그렇기 때문에 실제 힙에 들어있는 인스턴스를 가리키는 작업을 Resolve 시점에 해주게 된다.

실행 엔진 (Execution Engine)

실행 엔진은 클래스 로더를 통해 런타임 데이터 영역에 배치된 바이트 코드를 명령어 단위로 읽어서 실행한다. 앞서 이야기했듯이 .class파일은 온전히 os가 인식할 수 있는 byte code가 아니다. 그래서 실행 엔진은 이와 같은 코드를 실제로 기계가 실행할 수 있는 형태로 변경해준다.
이 수행 과정에서 실행 엔진은 인터프리터와 JIT 컴파일러 두 가지 방식을 혼합하여 바이트 코드를 실행한다.

인터프리터(Interpreter)
바이트 코드 명령어를 하나씩 읽어서 해석하고 바로 실행한다.
JVM안에서 바이트코드는 기본적으로 인터프리터 방식으로 동작한다. 다만 다른 인터프린터 언어처럼 전체적인 속도는 느리다.

JIT 컴파일러(Just-In-Time Compiler)
위의 Interpreter의 단점을 보완하기 위해 도입된 방식으로 반복되는 코드를 발견하여 바이트 코드 전체를 컴파일하여 Native Code로 변경하고 이후에는 해당 메서드를 더 이상 인터프리팅 하지 않고 캐싱해 두었다가 네이티브 코드로 직접 실행하는 방식이다. 하나씩 인터프리팅하여 실행하는것이 아니라, 컴파일된 네이티브 코드를 실행하는 것이기 때문에 전체적인 실행 속도는 인터프리팅 방식보다 빠르다.하지만 바이트코드를 Native Code로 변환하는 데에도 비용이 소요되므로, JVM은 모든 코드를 JIT 컴파일러 방식으로 실행하지 않고 인터프리터 방식을 사용하다 일정 기준이 넘어가면 JIT 컴파일 방식으로 명령어를 실행하는 식으로 진행한다.

가비지 컬렉터 (Garbage Collector ,GC)

가비지 컬렉터는 Heap메모리에서 더는 사용하지 않는 메모리를 자동으로 회수한다. 하지만 GC가 발생할 때 앞서 말했던 Thread 동기화로 인한 성능 이슈가 발생할 수 있다. 더 자세한 내용은 다음을 참고하자

가비지-컬렉션GC-동작-원리-알고리즘

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

런타임 데이터 영역은 위 그림과 같이 크게 Method Area, Heap Area, Stack Area, PC Register, Native Method Stack로 나눌 수 있다.

PC Register

현재 수행 중인 instruction의 주소
JVM은 Stacks-Base 방식으로 작동하는데, JVM은 CPU에 직접 Instruction을 수행하지 않고, Stack에서 Operand를 뽑아내 이를 PC Register에 저장한다.
-> 여기서 Stacks-Base방식이란 연산을 수행하기 위해 스택이라는 데이터 구조를 사용하는 방식을 말한다. 스택은 데이터를 저장하는 구조로, 나중에 들어간 데이터가 먼저 나오는 '후입선출' (LIFO: Last In First Out) 방식을 따른다.

프로그램의 실행은 CPU에서 명령어,즉 instruction을 수행하는 과정으로 이루어진다. CPU는 이러한 Instruction을 수행하는 동안 필요한 정보를 레지스터라고 하는 CPU내의 기억장치를 사용한다.
하지만 Runtime Data Area의 메모리 영역인 PC Register는 이것과는 다르다. Java는 Register-Base로 구동되는 방식이 아니라 Stack-Base로 작동한다. JVM은 CPU에 직접 Instruction을 수행하지 않고 Stack에서 Operand를 뽑아 내어 이를 별도의 메모리 공간에 저장하는 방식을 취하고 있는데 이것이 PC Register이다.
이렇게 JVM이 자체적인 가상의 레지스터를 사용함으로써, Java 프로그램은 다양한 하드웨어와 운영체제에서 동일하게 작동할 수 있게되는 것이다.

메서드 영역 (Method Area)

메서드 영역은 JVM이 시작될 때 생성되는 공간으로 실행파일을 처음 메모리 공간에 올릴 때 초기화되는 대상을 저장하기 위한 메모리 공간이다.
JVM이 동작하고 클래스가 로드될 때 적재되서 프로그램이 종료될 때까지 저장 된다.

모든 쓰레드가 공유하는 영역이라 다음과 같이 초기화 코드 정보들이 저장되게 된다.

Field Info : 멤버 변수의 이름, 데이터 타입, 접근 제어자의 정보
Method Info : 메소드 이름, return 타입, 함수 매개변수, 접근 제어자의 정보
Type Info : Class 인지 Interface 인지 여부 저장, Type의 속성, 이름 Super Class의 이름

힙 영역 (Heap Area)

힙 영역은 메서드 영역와 함께 모든 쓰레드가 공유하며, 런타임에 동적으로 할당된 데이터들의 저장소이다.
즉, new 연산자로 생성되는 클래스와 인스턴스 변수, 배열 타입 등 Reference Type이 저장되는 곳이다.

유의할점은 힙 영역에 생성된 객체와 배열은 Reference Type으로서, JVM 스택 영역의 변수나 다른 객체의 필드에서 참조된다는 점이다. 만일 참조하는 변수나 필드가 없다면 JVM은 쓰레기 수집기인 Garbage Collector를 실행시켜 쓰레기 객체를 힙 영역에서 자동으로 제거된다.

스택 영역 (Stack Area)

스택 영역은 int, long, boolean 등 기본 자료형을 생성할 때 저장하는 공간으로, 임시 변수 저장영역이다.
메서드 호출 시마다 각각의 스택 프레임이 생성되고 메서드 안에서 사용되는 값들을 저장하고, 호출된 메서드의 매개변수, 지역변수, 리턴 값 및 연산 시 일어나는 값들을 임시로 저장한다. 그리고 메서드 수행이 끝나면 프레임별로 삭제된다.

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

네이티브 메서드 스택는 자바 코드가 컴파일되어 생성되는 바이트 코드가 아닌 실제 해당 OS에서 실행할 수 있는 기계어로 작성된 프로그램을 실행시키는 영역이다.
또한 자바 이외의 언어(C, C++, 어셈블리 등)로 작성된 네이티브 코드를 실행하기 위한 공간이기도 하다.
앞서 이야기한대로 JIT컴파일러에 의해 변환된 Native Code역시 여기에서 실행이 된다고 보면 된다.