[Java] JVM

Bootstrap Class Loader : 가장 필수가 되는 Library class들을 load (e.g.) rt.jar
Extension Class Loader : Bootstrap 다음으로 중요한 classes를 load (e.g.)$JAVAHONE/jre/lib/ext/*.jar
Application Class Loader : 개발자가 작성한 클래스 파일을 load (classpath에 위치)
ACL이 로딩 요청 받아서 상위로, 또 상위로 위임. 위쪽에서 찾기 실패 시 하위로 요청 패스. 결국 못 찾으면 ClassNotFound Exception 발생.

Linking

Verification : 클래스 파일이 올바른 지 검증
Preparation : 클래스, 인터페이스에 필요한 static field 메모리 할당 및 기본값 초기화
Resolution : Symbolic Reference 값을 Method Area의 Direct Reference (메모리 주소) 값으로 변환

Initialization

멀티 쓰레드로 동작하기 때문에 동시성 고려

Loading, Linking 후에 Class 파일의 코드를 읽음
클래스와 인터페이스의 값들을 지정한 값으로 초기화 (기본값 초기화는 linking)

Method Area (= PermGen = Metaspace = Non-Heap)

메소드 에어리어는 모든 클래스의 메타 정보 (클래스 이름, 필드 변수명, 메소드 이름, 열거형 등)이 저장되는 곳이다. JVM 내에 하나만 존재하며 여러 클래스들 사이에서 공유된다.

Method Area는 PermGen(java 7까지) Metaspace(java 8 이후)의 일부이다.

PermGen은 뭐고, Metaspace는 또 뭘까?

간단한 그림 한 장으로 알아보자.

그냥 이름이 바뀐거다.

Interned String과 static variable, static method 등은 PermGen이라고 하는 기억공간에 저장이 따로 되는데, Java 8부터 이 공간의 이름이 Metaspace로 변경되었고, Heap 영역에서 Native Memory 영역으로 위치가 변하였다.

이게 무엇을 뜻하느냐? JVM이 아닌 OS에 의해 관리된다는 소리다.

다시 말해 가용영역 크기가 엄청나게 증가했다는 것이다.

그렇기 때문에 java.lang.OutOfMemoryError: PermGen space와 같은 에러는 이제는 볼 수 없는 과거의 유물이 되었다.

동시에 과거에는 PermGen에 static variable, static method 등이 클래스 메타 정보와 함께 저장이 되었는데, 변경 이후부터는 오직 클래스 메타 정보만을 저장하고, static member들은 Heap에서 관리된다.

Heap

Java로 구성된 배열이나 객체의 인스턴스 (Class 정보를 통해 new로 생성되는 객체) 정보와 static 변수, 메소드들의 정보가 저장되는 공간이다.

모든 Java stack 영역에서 참조되어, Thread 간 공유된다.

해당 영역이 모두 차면 OutOfMemoryException이 발생한다.

추가적인 특징은 다음과 같다.

내부적으로 Eden 영역, Survival 영역, Tenured 영역으로 나뉜다.
Eden + Survival을 묶어 Young Generation이며 Minor GC영역이다.
Eden 영역이 가득차면 Minor GC가 수행되며, 살아있어야 하는 객체들은 Survival 영역으로 넘어간다.
Minor GC 중에 Survial 영역에 있는 객체들 또한 확인되며, S0 or S1 중 한 쪽으로 모조리 이동한다. 그렇기 때문에 S0, S1 둘 중 하나는 항상 빈 공간이다.
여러 번의 GC에서 살아남은 객체들은 Old Generation 영역으로 넘어간다.
Tenured 영역이 Old Generation이고 Major GC영역이다.
Tenured 영역이 가득 차면 Major GC가 수행되며, 이 GC 과정은 영역의 덩치가 크기에 오래 걸린다.

PC Register

Thread별로 동시에 동작할 수 있도록 메모리 주소를 저장한다.

Stack Area

Java의 메소드나 호출될 때 사용되는 메모리 공간이며, 변수, 오퍼레이션, reference 정보 등이 저장된다.

스레드마다 하나씩 배정되는 메모리 영역이다.

Native Method Stack

Java가 아닌 다른 언어 (C, C++ 등)으로 작성된 메소드들의 정보가 저장되는 곳이다.

Native Method Interface / Library

Native Method Library는 Java가 아닌 언어에 대한 라이브러리 정보를 담고 있으며,

Native Method Interface는 이 라이브러리들과 JVM 사이에서 소통 창구 역할을 한다.

Stack vs Heap

차이점을 알아보자.

속성	Stack	Heap
사용성	호출 될 때만 스레드의 실행 중에 사용	어플리케이션 전체에서 실행시간 내내 사용함
Threadsafe	O	X (동기화 처리 필요)
크기	제한된 크기, 보통 Heap보다 작음	유저 설정 or 기본값에 따름. OS로부터의 제한은 없음
저장대상	privitive 변수와 객체의 참조 변수	new 커맨드로 생성된 객체
생명주기	현 메소드가 끝날 때까지	어플리케이션이 죽을 때까지
속도	상대적으로 빠름	상대적으로 느림
Alloc/Dealloc	메소드가 호출되고 결과를 반환 할 때 자동으로 됨	객체가 생성될 때 할당되고 GC에 의해 해제됨

Execution Engine

Interpreter

Python 등에도 있는 그 인터프리터와 같은 기능으로, 바이트코드를 한 줄 씩 읽어서 실행한다. 그렇기 때문에 실행 시간이 길어지면 길어질수록 느린 것이 특징이다.

JIT Compiler

인터프리터가 너무 느려서 나온 보완책이다.

유사한 바이트코드를 기계어로 번환한다. 이 과정은 인터프리터와 같지만, 변환된 기계어를 저장한다는 점이 다르다. 이렇게 저장된 기계어는 동일 코드가 호출될 때마다 제공되어 추가의 변환시간을 필요로 하지 않게 된다.

그렇기 때문에 JIT Compiler는 반복 호출되는 바이트코드 부분이 많으면 많을 수록 효율이 올라간다.

그러면 얼마나 호출되는지 확인하는 것은 뭐가 어떻게 하느냐?

Hotspot Compiler가 바로 그 역할을 한다. 이 친구는 우선 순위가 높은 코드가 낮은 코드보다 먼저 컴파일되도록 Java 코드를 식별하고 우선 순위를 지정한다. 그 후, 우선 순위에 따라 JIT Compiler가 설정 된 기준을 넘어가는 코드들을 변환하고, 이후에 인터프리터가 남은 코드를 변환한다.

기계어로 변환된 코드는 Non-Heap 안의 또 다른 저장 공간인 Code Cache에 담겨져 추가적인 변환없이 빠르게 실행될 수 있게 된다.