[F-Lab Mentoring] JVM 1탄

🖥 JVM의 구성요소

JVM은 javac로 변환된 "자바 바이트 코드 (.class) "를 실행할 수 있는 가상 컴퓨터

1. 클래스 로더 시스템

• 클래스를 메모리로 로드하는 역할
• JVM은 부모 우선(Parent-First) 위임 모델로 로딩
  클래스를 로드할 때 먼저 부모 로더에게 위임하고, 부모가 찾지 못한 경우에만 자신이 직접 로드

 

2. 런타임 데이터 영역

• 프로그램 실행 중에 사용되는 데이터를 저장
• 스레드마다 독립적인 공간(Stack, PC, Native Stack)과 모든 스레드가 공유하는 공간(Heap, Metaspace)으로 나뉨

 

3. 실행 엔진

• 로드된 바이트 코드를 실제 실행 (interpreter, JIT Compiler, Garbage Collector)
      - Interpreter: 바이트 코드를 한 줄씩 해석하며 실행
      - JIT Compiler: 자주 실행되는 코드를 기계어로 컴파일해 성능 최적화
      - Garbage Collector: 더 이상 참조되지 않는 Heap 객체를 수거

 

4. 네이티브 인터페이스

• JVM과 OS/하드웨어 간 상호작용을 지원
• native 키워드가 붙은 메서드는 자바 코드가 아닌 OS 레벨 라이브러리(C/C++ 등)를 호출
• Native Method Libraries는 네이티브 메서드 실행에 필요한 라이브러리, 이를 포함하고 있음

 

Q. 네이티브(Native)란?

• 네이티브 코드 = 자바가 아닌 OS/CPU용 기계어로 직접 작성된 코드를 의미
• 대부분 C/C++로 구성. (예: OpenSSL 라이브러리, OS 시스템 콜)
• 그래서 native 키워드가 붙은 자바 메서드는 자바 코드가 아니라 OS 레벨 라이브러리(C 등)를 호출한다는 의미
  👉  “네이티브”가 곧 “C”를 뜻하는 건 아니고, 보통 C/C++로 작성된 OS 연동 코드라는 걸 의미

 

---

 

🔒 JVM 메모리 구분

JVM에서 메모리를 담당하는 구성요소는 "런타임 데이터 영역"
여기서는 <모든 스레드가 공통으로 사용하는 영역>과 <스레드 별 할당되는 영역>으로 구분

 

<모든 스레드가 공통으로 사용하는 영역>

1. 메서드 영역 (HotSpot에서는 Metaspace)

• JVM이 시작될 때 생성되는 공간이며 클래스 데이터(바이트 코드)가 여기에 저장
  👉  클래스 로딩 시 올라가는 클래스 관련 메타데이터 저장소
• 클래스 메타데이터, 런타임 상수 풀(RCP), 바이트코드가 저장되고 모든 스레드가 공유
  (※ static 필드 “값”은 Heap의 Class<T> 객체에 저장)
• Method Area/Metaspace에는 static 변수의 정의에 대한 정보(“static 필드가 있다”는 메타데이터)가 올라감
  static 변수의 실제 값은 Heap의 Class<T> 객체 안에 저장됨!
  👉  static 변수는 논리적으로는 Method Area, 실제 HotSpot 구현에서는 Heap(Class 객체)에 값 저장

[Method Area / Metaspace]
   ├─ Class A Metadata
   │     ├─ static 필드들
   │     ├─ 메서드/필드 정보
   │     └─ Runtime Constant Pool (클래스 A 전용)
   │            ├─ "Hello" → (실행되는 시점에 Heap의 String 객체 참조)
   │            ├─ 숫자 123
   │            └─ 메서드 핸들 심볼 등
   ├─ Class B Metadata
   │     └─ Runtime Constant Pool (클래스 B 전용)
   ...

• 구성요소
  1) 클래스 이름, 부모 클래스, 인터페이스 정보
  2) 메서드/필드의 시그니처(타입, 접근 제어자 등)
  
  3) 런타임 상수 풀(Runtime Constant Pool)          ← 각 클래스마다 독립적으로 존재
      . 클래스 로딩 시, .class 파일 안에 있던 Constant Pool 정보를 JVM 메서드 영역에 올려놓고, 필요하면 힙 객체(예: String 리터럴) 참조도 같이 저장
            - 심볼(Symbol): 클래스 이름, 메서드 이름, 필드 이름 같은 “문자열 식별자”
            - 리터럴(Literal): 숫자 10, 문자열 "Hello", 상수 값 같은 것
  
            "Hello"라는 문자열 리터럴이 코드에 등장하면, 해당 클래스의 상수 풀 항목에 "Hello"라는 엔트리가 기록됨
            런타임 상수 풀의 "Hello" = 처음에는 단순 “상수/기호” 정보
            실행 중 사용될 때 (constant pool entry가 resolve될 때_)
                 → Heap의 String 객체와 연결되어, 그 객체를 가리키는 참조(주소값)를 들고 있는 슬롯이 됨.
  
            처음에는 목록, 하지만 실제 런타임에는 “목록 + Heap 객체 참조”로 동작.
            👉  RCP는 단순 값 저장소가 아니라 동적 연결/해석을 위한 테이블
  
       . 런타임 상수 풀은 단순한 값 저장소가 아니라, JVM이 동적 바인딩(메서드 호출 연결), 필드 참조 해석, 클래스 참조 해석 같은 작업할 때도 사용
       . JVM이 클래스 동작을 “해석하고 연결하는 데이터 구조”
  
  4) static 변수(정적 필드)
  5) 메서드 코드 자체(JIT 이전에는 바이트코드)

 

Q. HotSpot이란?

• JVM(Java Virtual Machine)의 구현체 중 하나
  OpenJDK = HotSpot이 기본 탑재
• HotSpot JVM의 특징은 JIT(Just-In-Time) 컴파일러가 들어있다는 점.
  → 그래서 인터프리터보다 빠르고, 정적 컴파일보다도 상황에 맞춰 최적화 가능.
• HotSpot = 자주 실행되는 코드를 캐치해서 최적화하는 JVM.
• JVM = 여러 GC 엔진을 품고 있는 플랫폼
  예) Serial GC, Parallel GC, CMS (deprecated), G1GC, ZGC, Shenandoah
• 하나의 JVM 프로세스에서 동시에 여러 GC를 혼용할 수는 없으므로 실행할 때 하나의 GC 알고리즘만 선택해서 사용
• HotSpot JVM은 버전에 따라 기본 GC가 다르다
  Java 8 → Parallel GC
  Java 9 이후 → G1GC
  Java 11/17 이후 → G1GC 여전히 기본, 하지만 ZGC/Shenandoah도 선택 가능

 

2. 힙 영역 (Heap)

• 실행 중에 동적으로 생성된 객체와 배열이 저장되는 영역, 자동 초기화 발생
• new 연산을 통해 생성된 변수 (Reference Type에 해당 - class, interface, enum, Array)
• GC(Garbage Collector)의 타겟이 되는 영역이므로(할당 해제) GC를 위해 일반적으로 Young/Old Region 으로 나뉘어짐
  👉  HotSpot에서는 Eden/Survivor/Old Region 구조로 관리
• 구성요소
       1) 문자열 리터럴 풀 (String Literal Pool = Intern Pool)
              힙 안에서 해시테이블 기반으로 관리되는 전역 캐시
              "Hello" 같은 문자열 리터럴이 실제 객체로 만들어져 저장되는 공간
              모든 클래스가 공유한다. (클래스별로 따로 있지 않음)
              "Hello"가 여러 클래스에서 등장해도 하나의 객체만 생성되고, 그 참조가 상수 풀 항목에 연결
• String s = "Hello";
        "Hello" 문자열은 힙(Heap)에 String 객체로 존재함
        그런데 이 객체에 대한 참조(포인터)가 런타임 상수 풀 안에도 등록
        → 그래서 "Hello"라는 리터럴은 프로그램 전체에서 공유 가능
• static은 객체를 만들지 않아도 “정의”가 Metaspace에 올라간다.
  단, static 필드의 실제 값 저장소는 Heap의 Class<T> 객체 내부다.
  static 필드가 참조하는 객체는 Class<T> 객체(Heap)를 통해 GC Root로 도달 가능하다.
        참조가 가리키는 대상 객체는 Heap에 존재
        static List<String> cache = new ArrayList<>();
              이 cache는 GC Root라서 프로그램 끝날 때까지 안 지워짐(명시적으로 null 처리하지 않으면).
              또는 클래스 언로딩(class unloading) 이 일어나 클래스 자체가 GC 대상이 되고, 그 클래스의 static 필드 참조도 함께 사라짐
• String a = "Hello";  
  String b = new String("Hello");
         a: 리터럴 풀을 통해 Heap의 intern table에 있는 객체 참조 → 공유.
         b: Heap에 새로운 String 객체를 강제로 생성 → a와 b는 서로 다른 객체.
         하지만 b.intern()을 호출하면 b도 intern table의 "Hello" 참조를 돌려줌 → a와 동일해짐.
  
  

 

<스레드별 할당되는 영역>

3. 자바 스택

• 스레드의 메서드 호출과 로컬 변수를 저장하는 영역으로 스택 프레임은 생성되지만 로컬 변수의 자동 초기화가 이루어지지 않으므로 사용 전 반드시 값 할당 필요(특히 primitive)
• 지역변수나 메서드의 매개변수, 호출된 메서드의 정보가 저장되는 영역
• 해당 메서드의 호출이 종료되면 사라짐 (할당 해제)!

 

4. 프로그램 카운터 (PC Register)

• 스레드가 시작될 때 생성
• 현재 실행 중인 JVM 명령의 주소를 저장 (스레드가 어떤 부분을 어떤 명령어로 실행 중인지 저장하는 공간)

 

5. 네이티브 메서드 스택

• Java가 아닌 다른 언어로 작성된 코드를 위한 공간
• Java Native Interface를 통해 호출하는 C/C++ 등의 코드를 수행하기 위한 공간
  👉  OS/네이티브 ABI 규칙에 맞춰 콜 스택/레지스터를 다루기 위해 자바 스택과 분리

 

Q. 왜 JNI 호출이 필요한가?

• 자바만으로 OS 기능을 다 다룰 수는 없음 (예: 파일 디스크립터, 시스템 콜, GUI)
• 고성능 라이브러리(C/C++로 작성된 DB 드라이버, 암호화 라이브러리)를 쓰기 위해
• JVM 내부 동작(스레드 생성, 메모리 관리 등)도 사실 OS API 호출이 필요

 

Q. ABI(Application Binary Interface)

• OS와 CPU가 정한 “바이너리 레벨 약속” >> Windows x64, Linux x64, ARM 등마다 호출 규약(calling convention)이 다름.
• 자바 스택 프레임은 JVM 전용 규약을 따르기 때문에, 네이티브 스택 프레임과 섞어 쓰려면 분리해서 관리가 필요

 

Q. Person p = new Person("Euiseon", 35);

• 이 때, 변수 p는 스택에 저장이 됨.
• new Person("이의선", 35)이라는 실제 Person 객체 데이터는 힙에 저장이 됨

 

Q. 그러면 변수 p가 저장된 스택의 메모리에는 주소값이 들어있는건가?

• 자바 언어 관점에서 p는 객체의 참조(reference)를 저장 == 힙 객체를 가리키는 일종의 주소값(raw pointer or compressed OOP)
  👉  자바 언어에서는 "주소값"이라는 표현 대신 참조라는 개념 사용

 

---

 

🎤 classloader란?

• .class 파일(바이트코드)을 찾아서 JVM의 메모리(Method Area/Metaspace)에 적재하는 역할을 하는 JVM의 구성 요소
• 로딩된 클래스는 JVM 안에서 java.lang.Class 객체로 표현
  👉  우리가 SomeClass.class라고 쓸 때의 그 객체!
• JVM에는 여러 단계의 로더가 존재하며 부모 우선(Parent-First) 위임 모델이라는 규칙으로 순차적 로딩
• 자바 프로그램이 A라는 클래스를 처음 참조하면, JVM은 클래스 로더 체인을 따라가며 .class를 읽어온 뒤, JVM 내부에 로딩
• 일반 체인: Bootstrap → Platform(Java 9+) → Application(System) → (사용자 정의 로더)

 

<구성요소>

1. Bootstrap ClassLoader

• 자바 핵심 라이브러리(java.lang.*, java.util.*)를 로드.
• C/C++로 작성된 네이티브 코드라서 자바 객체로는 존재하지 않음.
• Bootstrap ClassLoader는 “JVM 부팅(bootstrap) 단계에서 기본 클래스를 올리는 네이티브 로더” (웹 개발의 CSS 프레임워크 Bootstrap과 전혀 관계없음)

2. Platform ClassLoader (Java 9+)

• JDK의 표준 모듈 라이브러리
• 예: java.sql.*, java.xml.*

3. Application(System) ClassLoader

• 개발자가 classpath에 넣은 .class/JAR (서드파티 라이브러리 JAR)

4. 사용자 정의 로더

• 필요하면 우리가 직접 확장해서 만들 수 있음. (예: 네트워크에서 클래스를 가져오기, 암호화된 JAR 해제 후 로딩 등)

 

<클래스 로딩 과정>

1. 로딩 (Loading)

• 클래스 로더가 .class 바이트코드를 읽어서 JVM 내부 구조로 변환
• 이때 클래스의 구조(필드, 메서드, 상수풀 등)가 메서드 영역(Method Area/Metaspace)에 올라감
  👉  “A라는 클래스가 어떤 멤버를 갖는다”라는 메타정보가 생김

2. 링크 (Linking)

• 검증(Verify): 바이트코드 유효성 검사
• 준비(Prepare): static 변수에 메모리 공간 할당, 기본값(0, null)으로 초기화
• 해결(Resolve): 상수풀 참조를 실제 메모리 참조로 치환 (필요 시점에 지연되기도 함)

3. 초기화 (Initialization)

• static 변수의 실제 값 할당 (예: static int i = 10;)
• static 블록 실행
• 이 시점에 Heap에 Class<A> 객체가 생성돼서, A.class로 접근할 수 있게 됨
• static 필드 값들은 이 Class<A> 객체의 필드 안에 저장

로딩/링크
→ 메서드 영역(Metaspace)에 바이트코드 + 클래스 메타데이터 올라감 / static 변수에 메모리 공간 할당


초기화
→ static 필드에 값 채워짐
→ Heap에 Class<A> 객체 1개가 생성
→ 이 객체가 바로 우리가 A.class 라고 쓸 때 참조하는 대상

 

<Parent-first delegation model>

• 클래스 로더의 동작 방식 (여러 로더가 동시에 있을 때 누가 이 클래스를 로딩할지 정하는 규칙)
• Bootstrap ClassLoader: rt.jar 같은 JVM 핵심 클래스 로딩 (ex: java.lang.*)
  Platform ClassLoader : JDK 표준 모듈(java.*)을 로딩(Java 9+의 모듈 시스템 기반)
  Application (System) ClassLoader: 우리가 만든 애플리케이션 클래스 로딩 (classpath 지정된 것)
  필요하면 사용자 정의 ClassLoader도 만들 수 있음
• 자바 클래스 로더는 부모에게 먼저 위임(Delegation)하고, 부모가 못 찾았을 때만 자신이 직접 로딩
• 동작 순서
  어떤 클래스가 필요하면, 현재 클래스 로더가 부모에게 먼저 요청
  부모가 또 그 부모에게 요청 (최종적으로 Bootstrap까지 올라감)
  부모 체인 중 하나가 클래스를 찾으면 그대로 사용
  부모들이 못 찾을 경우에만 자식 로더가 직접 로딩
  즉, “항상 위에서부터 먼저 찾아보고, 없으면 아래가 책임진다”는 원리

 

Q. 왜 이렇게 Parent Delegation을 쓰는가?

• 보안: java.lang.String 같은 핵심 클래스는 무조건 Bootstrap에서 로드 → 누군가 내가 만든 String.class로 바꿔치기 불가
• 일관성: JVM 어디에서 호출하든 동일한 클래스는 동일한 ClassLoader가 로드한 하나의 Class 객체만 존재하도록 보장
• 유연성: 필요하다면 특정 클래스만 사용자 정의 로더로 커스텀하게 로드 가능

Q. Human 클래스를 내가 만들었다면?

• 실행 중 new Human() 호출 → JVM은 Human 클래스 로딩 여부 확인
  아직 로드 안 됨 → Application ClassLoader가 부모(Bootstrap, Platform)에게 위임
  부모 로더들은 Human을 못 찾음 → Application ClassLoader가 classpath에서 Human.class를 찾아 로드
  JVM 메타스페이스에 클래스 정보가 올라가고, Human 클래스의 static 블록/필드 초기화가 실행됨

 

---

 

⏳ 실행 엔진이란?

• 자바 바이트 코드를 기계어로 변환하여 실행
• Tiered Compilation 사용: JVM은 인터프리터로 먼저 실행 → 일정 기준(호출/루프 카운터) 넘으면 JIT 컴파일 진행

1. interpreter

• 실행 중에 바이트 코드를 한 라인씩 읽고 실행, 속도가 느려지는 현상 존재 (특히 반복문)

2. JIT Compiler

• 자바 프로그램이 실행될 때 바이트 코드를 기계어로 변환하는 과정에서 프로그램의 실행 패턴을 분석하여 자주 실행되는 코드(핫 스팟)를 중심으로 최적화를 수행
• JIT 컴파일러는 메서드 단위로 컴파일을 수행함
  👉  실행 초반에는 인터프리터로 실행하다가 호출/루프 카운터가 임계치를 넘으면 Tiered JIT가 그 메서드/루프를 네이티브로 컴파일함
• 메서드 단위의 컴파일은 실행 패턴에 따라 최적화를 수행 (동적 언어의 특성을 활용하는 방법)
• "자주 실행되는 바이트 코드 영역을 런타임 중에 기계어로 컴파일하여 사용"

 

3. 대표적인 최적화 예시

1) 인라이닝(Inlining)

• 작은 메서드 호출을 없애고 직접 코드로 치환
• int add(int a, int b) { return a+b; }
  int result = add(1,2);
  원래라면 add 메서드를 호출해야 하지만, JIT은 호출을 없애고 그냥 int result = 1+2;로 치환!
  메서드 호출 오버헤드 제거 → 빠름
  작은 메서드가 반복 호출될 때, 호출 오버헤드를 없애고 호출부에 코드 자체를 “직접 박아 넣는” 최적화

 

2) 탈가상화(Devirtualization)

• 가상 호출을 실제 호출로 바꿔 호출 오버헤드 제거
• List<String> list = new ArrayList<>();
  list.add("A");
  바이트코드 상으로는 List.add (인터페이스 메서드 호출) → 런타임에 어떤 구현인지 모름
  근데 JIT은 실제 객체 타입이 ArrayList임을 알면, 바로 ArrayList.add를 호출하도록 최적화
  자바는 보통 “가상 메서드 호출(virtual call)” 방식을 써요 → 런타임에 실제 타입을 찾아 호출
  JIT은 실행 중에 “항상 ArrayList로만 호출되네?” 같은 패턴을 발견하면, 매번 가상 디스패치하지 않고 바로 ArrayList.add()를 호출하도록 치환
  👉  “가상 호출을 실제 호출로 바꿔버린다 = 탈가상화”

 

3) Escape Analysis + Scalar Replacement

• 메서드 안에서만 쓰이는 객체라면 힙 대신 스택/레지스터에 두거나 아예 필드를 로컬 변수로 쪼개버려 GC 부담을 줄임
• class Point { int x, y; }
  void foo() {
    Point p = new Point();
    p.x = 1; p.y = 2;
  }
  보통 new Point()는 힙에 객체 생성.
  근데 JIT은 p가 메서드 안에서만 쓰이고 외부로 “탈출(escape)”하지 않는 걸 알면,
  아예 힙 객체를 안 만들고 그냥 로컬 변수 2개(int x, int y)로 치환
  👉  new조차 사라짐 → 객체를 스택/레지스터에만 두는 경우 “힙에 안 만들어서 GC 부담 줄어듦”
• Escape Analysis: 객체가 메서드 안에서만 쓰이고 바깥으로 나가지 않는다면, 힙에 안 만들고 스택/레지스터에서만 처리
• Scalar Replacement: 아예 객체를 쪼개서 필드를 각각 독립적인 로컬 변수로 치환

 

4) OSR(On-Stack Replacement)

• 긴 루프를 돌다가도 도중에 네이티브 코드로 치환해 성능 향상
• 반복문 같은 건 처음엔 인터프리터로 돌다가 “충분히 많이 반복되면” 루프 중간을 JIT이 네이티브로 바꿔치기
  긴 루프라도 실행 도중에 네이티브로 치환해서 속도 개선.

 

 

👉 실행 엔진은 인터프리터와 JIT을 병행하여  “처음엔 느리게 시작 → 점점 빨라진다”는 게 자바 실행 특성
       == 런타임 최적화 특성을 가진다.