🦈 JVM 정리 🦈

JVM

Java Virtual Machine
Java를 실행하기 위한 가상 머신, Java API와 함께 실행

• Java application은 JVM 위에서 동작하지 않음 > OS 종속적 X
• Garbage Collection을 통한 메모리 관리 > 자동 메모리 최적화
• Stack 기반 가상 머신
• Class Loader, Execution Engine, Runtime Data Area으로 이루어짐

동작 과정

1. 프로그램 실행 시 JVM은 OS로부터 메모리 할당
2. Java Compiler(Javac)가 Java Source code(.java)를 Java byte code(.class)로 Compile
3. Class Loader는 동적 로딩을 통해 필요한 클래스들을 Loading, Linking해 Runtime Data Area에 올림
4. Runtime Data Area에 Loading된 byte code는 Execution Engine을 통해 해석
5. 이 과정에서 Execution Engine에 의해 Garbage Collector의 작동과 Thread 동기화가 이루어짐

구성

• Class Loader
• Execution Engine
  • Interpreter
  • JIT Compiler
  • Garbage collector
• Runtime Data Area
  • Method Area
  • Heap Area
  • PC Register
  • Stack Area
  • Native Method
• JNI - Native Method Interface
• Native Method Library

Class Loader

jar 파일 내 저장된 클래스를 동적으로 JVM의 Heap에 탑재하는 역할

• .class 파일을 로드 - 프로그램이 실행 중인 Runtime에서 모든 코드가 JVM과 연결
• Loading 시 한번에 메모리에 올리지 않고, 어플리케이션에서 필요한 경우 동적으로 메모리 적재

Loading 순서

• Loading : 클래스 파일을 가져와 JVM의 메모리에 로드
• Linking : 클래스 파일을 사용하기 위해 검증
  • Verifying(검증) : 읽어들인 클래스가 JVM 명세에 맞는지 검사
  • Preparing(준비) : 클래스가 필요로 하는 메모리 할당
  • Resolving(분석) : 클래스의 상수 풀 내 모든 심볼릭 레퍼런스를 다이렉트 레퍼런스로 변경
• Initialization : 클래스 변수들을 적절한 값으로 초기화
  ex) static 필드들을 설정된 값으로 초기화

Compile

컴퓨터의 고급 언어로 작성한 코드를 기계어로 번역하는 과정

Compiler

프로그램 전체를 스캔해 기계어로 번역

• 전체를 스캔해 초기 스캔이 오래 걸림
• 이전에 만들어 놓았던 실행파일을 실행하기 때문에 전체 실행 시간에서는 Interpreter보다 빠름
• 하지만 기계어 번역 과정에서 Object Code 파일을 만드는데, 이를 묶어 하나의 실행 파일로 다시 만드는 Linking 작업때문에 Interpreter보다 많은 메모리 사용
• 오류 메시지 생성 시 전체 코드 검사 후 생성 => 실행 전 오류 발견 가능
  ex) C, C++, Java 등

Interpreter

Compiler와는 반대로 프로그램 실행 시 한 번에 한 문장씩 번역

• Compiler보다 실행 시간이 오래 걸림
• Compiler와 달리 Object Code 파일을 생성하거나 Linking 작업을 하지 않기 때문에 메모리 효율 더 좋음
• 프로그램을 한 문장씩 실행시키면서 오류를 만나면 바로 프로그램을 중지 => 프로그램을 실행해야만 오류 발견 가능
  ex) Python, Ruby, JavaScript 등

Compiler vs Interpreter

설명	Compriler	Interpreter
스캔 영역	전체	한 번에 한 문장
실행 시간	인터프리터보다 빠름	컴파일러보다 느림
메모리 효율	인터프리터보다 안좋음	컴파일러보다 좋음
오류 메시지	전체 코드 검사 후 생성	오류 만나면 중지

Execution Engine

Class Loader를 통해 Runtime Data Area에 배치된 byte code를 명령어 단위로 읽어서 실행

• Interpreter와 JIT(Just In Time)으로 클래스 실행
• Garbage Collector로 사용하지 않는 메모리를 찾아 삭제

JIT(Just In Time)

인터프리터 방식으로 실행하다가 적절한 시점에 바이트 코드 전체를 컴파일 -> Native code로 변경하고, 이후에는 더 이상 인터프리팅하지 않고 Native Code로 직접 실행

• 인터프리터의 단점(속도 느림) 보완을 위해 도입
• Native Code
  • Java에서 부모가 되는 C언어, C++, 어셈블리어로 구성된 코드
  • 캐시에 보관됨
  • 컴파일 시 바뀐 부분만 컴파일하고 나머지는 캐싱된 코드를 수행
    => 한 번 컴파일된 코드는 빠르게 수행

RunTime Data Area

프로그램 수행을 위해 운영체제로부터 할당받은 메모리 영역

Heap Area

객체 정보를 저장하는 가상의 동적 메모리 할당 영역

• 모든 Thread에서 접근 가능한 공유 메모리 영역
• new 연산자를 통해 객체를 Heap 메모리에 전달
• 할당된 객체는 직접 해제가 불가능하며, 주기적으로 GC가 제거

Garbage Collector(GC)

JVM의 Heap 영역에서 동적으로 할당했던 메모리 중 필요 없게 된 메모리 객체(Garbage)를 모아 주기적으로 제거하는 프로세스

• GC가 메모리 관리를 자동으로 해줌으로써 개발자가 개발에만 집중할 수 있게 됨
• 실행이 끝난 뒤 버려지는 객체들을 주기적으로 비워줌으로써 한정된 메모리를 효율적으로 사용할 수 있게 해줌
• 메모리가 언제 해제되는지 정확히 알 수 없어 제어하기 힘듦
• GC가 동작하는 동안 JVM이 다른 동작을 멈추기 때문에 Overhead 발생(Stop-The-World) > 소프트웨어 성능 하락 원인
• 어플리케이션의 사용성을 유지하면서 효율적이게 GC를 실행하는 최적화 작업이 필요 > GC 튜닝

Stack Area

• 메서드 호출 시 생성되는 스레드 수행정보를 기록하는 Frame 저장
• 메서드 정보, 지역 변수, 매개변수, 연산 중 발생하는 임시 데이터 저장

Method Area

JVM에서 읽어들인 클래스와 인터페이스에 대한 상수 풀, 메서드와 필드, static 변수, 메서드 바이트 코드 등을 보관

PC Register

• 연산 및 결과값을 메모리에 전달하기 전 CPU 내 기억장치
• 현재 실행 중인 JVM 주소를 가지며, CPU 명령어(=Instruction) 수행
• CPU Instruction 수행 동안 필요한 정보를 CPU 내 기억 장치인 Register에 저장

Native Method Stack

자바 외의 언어로 작성된 Native code를 위한 메모리

• C, C++ 등의 코드를 수행하기 위한 스택
• Native 메서드의 매개변수, 지역변수 등을 바이트코드로 저장

Heap Area와 Method Area는 JVM 시작 시 생성되고, 종료 시 해제됨
나머지 Area는 Thead 생성 시 생성, 종료 시 해제

이미지 출처 및 참고-JVM
참고-Compile, Compiler와 Interpreter
참고-JVM 내부 구조
참고-Garbage Collection